对DDD的一些概念感到困惑

Question

我有一些关于DDD概念的问题:

1. 在Evans关于DDD的书中，在VALUE OBJECTS一节中，他说要把组成一个概念整体的属性放在VALUE OBJECTS中，就像他的Address OBJECTS的例子一样。除了将属性留在Customer实体中，我似乎看不出这样做有什么好处。将其移出Customer，使其成为VALUE对象，然后在Customer中引用VALUE对象，我将获得什么?请举一些实际的例子

2. 也可以在VALUE对象上使用规范吗?

3. 实体对象的所有属性是其他实体对象和/或值对象吗?或者它们可以有原语吗?

4. 浏览互联网时，我看到有人说setter(和getter ?)是邪恶的，它们应该被避免，并被对域对象有意义的操作所取代。

例如:

Account.Balance = 100;  // set via property setter

应:

Account.DebitToAccount(100); // this would change the balance

在这个例子中，我可以理解他们的意思，但是对于一些常见的属性，如FirstName, midlename, LastName呢?我认为为每个属性设置方法(如ChangeName())是乏味和毫无意义的。假设我们选择了ChangeName()这样的方法，那么对于没有其他可分组属性的属性该怎么办呢?例如，输入Title?我们也应该有一个ChangeTitle()吗?(标题只是一个例子，请不要说我可以将标题分组到其他属性)

Answer 1

1. 域概念的封装。Address不只是任意字符串，Price也不是任意数字/十进制。VO表示表示为对象的Domain概念的有效值。注意，'a'值并不意味着封装1个原语。你可以在这里看到一个例子，我是如何建模一些值对象的。

2. 。

3. 这不是规则。实体的属性应该具有更有意义的类型。一些代表领域概念，其他代表更一般的概念(如电子邮件)，其他只是原语。

4. 不是真正的DDD，这是正确的OOP。关键是要封装行为。设置属性只是一个简单的赋值。DebitToAccount是对象的语义行为，只能作为属性赋值来实现。事情很容易改变，你只希望那个对象知道那些实现细节。行为本身保持不变，实现可以随时更改(例如:需要新的业务规则)。

至少在c#中你不需要真正的ChangeName()，你可以把它的实现放在setter中。在这种情况下，没有规则，甚至没有原则，这取决于开发人员的风格。