DDD和Getters和Setters的使用

Question

我讀過一些關於使用Getters和Setter的文章/文章，以及它們如何幫助打破域模型對象封裝的目的。我理解不使用setter的邏輯 - 您允許客戶端代碼在對象業務規則和不變量的上下文之外操作該對象的屬性。

現在這位校長仍然困惑我。例如，如果我需要更改對象的成員變量的值，會發生什麼情況？例如，如果某人的姓名發生變化，我怎麼能在模型中反映出這一點？起初，我想，爲什麼不能有一個名爲'ChangeName'的函數讓我傳入新名稱，然後又可以更改內部'名稱'變量。那麼....這只是一個二傳手是不是！

我需要澄清 - 如果我要完全消除setter，那麼在上述情況下，我應該完全依賴構造函數參數嗎？我是否應該通過構造函數傳遞新的屬性值來代替舊的屬性值，之後我可以通過將對象傳遞給我擁有的任何持久性基礎結構來堅持更改。

這兩篇文章中討論是有益的：

1. http://kellabyte.com/tag/ddd/
2. http://typicalprogrammer.com/?p=23

Answer 1

嗯，這是一個典型的討論。 Stack Overflow中有幾個其他的線程關於這個。

但是。 Get/Set的（自動屬性？）並不全是壞的。但是他們往往會讓你將實體構建爲只有prop和not方法的「死」數據容器。這種跡象通常被稱爲貧血領域 - 並且行爲很少。我的建議是：

1. 儘量少使用道具。
2. 試圖找到屬於一起的數據組，應該像 一樣像前。名字中間名和姓氏。另一個例子 是Zipcode，City，Street。這些數據最好通過 方法進行設置。它最大限度地減少了您的實體無效的機會。
3. 通常屬於一起的數據可以分組爲一個值 對象。
4. 更多價值對象傾向於從實體中引出更多描述性方法 ，它們是「動詞」而不是通常的「名詞」 實體。
5. 您的價值對象的更多方法也打開了添加更多 的行爲，並可能減少您的「胖」服務（也許您不要 有太多泄漏業務邏輯的服務......）。

這裏還有更多要說的......但一個簡短的答案。 關於在構造函數中設置數據：我只是這樣做，如果這個實體不能在沒有這些數據的情況下「活着」/存在。對於實體人，我會說名稱可能不是那麼重要。但社會安全號碼可能是建設者數據的候選人。或實體員工必須擁有公司的構造函數，只是因爲員工必須屬於公司。