困惑于一些DDD概念

Question

我对一些DDD概念有一些疑问：

1. 在埃文斯＆＃39;关于DDD的书，在VALUE OBJECTS部分，他说要在VALUE OBJECTS中放置构成概念整体的属性，就像在他的Address对象示例中一样。我似乎无法看到这样做的好处，而不仅仅是将属性留在Customer实体中。将它移出客户，使其成为一个有价值的对象，然后在客户中引用VALUE OBJECT，我会获得什么？请举出一些实际的例子。

2. 是否可以在VALUE OBJECTS上使用规格？

3. ENTITY OBJECTS的所有属性是其他ENTITY OBJECTS和/或VALUE OBJECTS吗？或者他们可以有原始人吗？

4. 浏览互联网时，我看到一些人说安装者（和吸气剂？）是邪恶的，他们应该避免使用，并替换为对域对象有意义的操作。

   < / LI>

   例如：

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

   应该是：

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

   在这个例子中，我可以理解它们所暗示的内容，但是对于FirstName，MiddleName，LastName等常见属性呢？我认为为每个属性设置方法（如ChangeName（））是乏味且毫无意义的。假设我们已选择使用类似ChangeName（）的方法，那么对于没有其他可分组属性的属性又如何呢？例如，说标题？我们也应该有ChangeTitle（）吗？ （标题只是一个例子，请不要说我可以将Title分组到其他一些属性）

Answer 1

1. 域概念的封装。地址不仅仅是任何字符串，价格不是任何数字/小数。 VO表示以对象表示的域概念的有效值。请注意＆＃39; a＆＃39;值并不意味着封装1个原语。您可以see here举例说明我如何为某些价值对象建模。

2. 没有。

3. 这不是一个规则。实体的属性应该是更有意义的类型。一些代表域概念，另一些代表更一般的概念（如电子邮件），其他代表原始概念。

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

至少在C＃中你并不真正需要ChangeName（），你可以将实现放在setter中。没有规则，在这种情况下甚至不是原则，它取决于开发人员的风格。