DDD和Getters and Setters的使用

Question

我已经阅读了一些关于Getters和Setter使用的文章/帖子,以及它们如何帮助破解域模型对象中封装的目的.我理解不使用setter背后的逻辑 - 你允许客户端代码在对象业务规则和不变量的上下文之外操纵该对象的属性.

现在这位校长仍然困惑我.例如,如果我需要更改对象的成员变量的值,会发生什么？例如,如果某个人的姓名发生变化,我该如何在模型中反映出来？起初我想,为什么没有一个名为'ChangeName'的函数让我传入新名称,然后又可以改变内部'name'变量.嗯....那只是一个二传手不是吧!

我需要澄清的是 - 如果我要完全消除setter,那么在上述情况下,我是否应该完全依赖构造函数参数？我应该通过构造函数传递新的属性值来代替旧的属性值,之后我可以通过将对象传递给我拥有的任何持久性基础结构来持久化更改吗？

这两篇文章在这个讨论中很有用:

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

Answer 1

嗯,这是一个经典的讨论.Stack Overflow中还有其他一些关于此的线程.

但.获取/设置(自动属性？)并不全是坏事.但是它们倾向于使您将实体构建为"死"数据容器,只有prop而不是方法.这种迹象通常被称为贫血领域 - 并且行为很少.我的建议是:

1. 尝试尽可能少地使用道具.
2. 尝试找到属于一起的数据组,并且应该像ex那样在一起.名字中间名和姓氏.另一个例子是Zipcode,City,Street.这些数据最好通过方法设置.它可以最大限度地降低您的实体无效的可能性.
3. 通常,属于一起的数据可以归为Value对象.
4. 更多Value对象倾向于从您的实体中引出更多描述性方法,即"动词",而不是通常的"名词"实体.
5. 您的价值对象的更多方法也可以用于添加更多行为,并可能减少您的"胖"服务(也许您没有太多泄露的业务逻辑的服务......).

这里还有更多要说的......但答案很简短.关于在构造函数中设置数据:如果没有该数据,此实体不能"生存"/存在,我只会这样做.对于实体人我会说Name可能不是那么重要.但社会安全号码可能是构造函数数据的候选者.或者实体员工必须在构造函数中拥有公司,仅仅因为员工必须属于公司.