DDD 记录 实体&值对象&服务

至少有3种方法可以使得关联更易于控制：
1. 指定一个导航的方向。
2. 通过加入限定符来有效地减少关联的多重性。
3. 清除不必要的关联。

例如：
美国和其他国家一样有过许多位总统，这就是一个双向的一对多的关联。但是，我们很少会提及乔治华盛顿这个名字时，问“他是哪个国家的总统”。所以我们就可以讲这种双向关联简化为一个单向关联。

经过深入的理解后往往可以得到一个“限定的”关系。我们会发现一个国家在一个时期只会有一个总统。这个限定条件将一对多关联简化为一对一关联，并且作为一条明确的重要规则包含在模型中，如 美国1790年时的总统是谁？乔治华盛顿。

对一个多对多关联的导航方向进行约束，会将它有效地简化为一对多这样更简单的设计。

不是在所有的业务活动中都可以这样简化。但是，无论什么特定的规则，只要发现了对象间关联的约束，就应该将它包含到模型和实现中来。这些约束使模型更加精确，也使实现更易于维护。


实体建模

当对一个对象进行建模时，我们会很自然地想到它的相关属性，对其行为的考察也非常重要。但是实体最基本的职责是保证连续性，以便使之具有清晰、可预见的行为。要更有效地实现这个目的，我们必须保持实体的精简性。对于实体而言，我们关注的重点不是它们的属性或行为，而应该把繁枝茂叶从定义中剔除出去，只留下那些固有的特性，特别是那些用来唯一标识对象，以及经常用来查找和匹配对象的特征。只加入核心概念所涉及到的行为，以及行为需要的属性。此外，想办法将属性和行为转移到与核心实体想联系的其他对象中去。这些对象可能是其他实体，也可能是值对象。

customerID是Customer实体的标识，也是其唯一的标识。但是电话号码和地址都经常被用来查找或匹配客户（所以目前先将这些属性放入Customer里面）。这种选择将取决于领域中的对象是怎样匹配和区分的。例如，如果客户有多个联系电话，那么电话号码就不具备唯一性，因此应该把它放在Sales Contact中。


值对象

如果一个对象代表了领域的某种描述性特征，并且没有概念性的标识，我们就称之为值对象。值对象就是那些在设计中我们只关心它们是什么，而不关心它们谁是谁的对象。

一个值对象可以是其他对象的集合。如窗户是由其他值对象组成的复杂的值对象。

值对象甚至可以引用实体。例如，假设我申请了一个地图服务，这里面有一个路线Route对象，它其中就包含了几个对象实体（城市和城市之间的高速公路）。

值对象通常作为参数在对象之间交换信息。他们通常是临时对象，在一个操作中创建了之后马上被丢弃了。值对象经常作为实体的属性和其他值。一个人可以被建模成一个实体，但是人的名字时一个值。

如果我们只关心模型中一个元素的属性，那么就把这个元素划分为值对象。用它来描述它所要表达的那些属性的意义，并提供相应的功能。把值对象看成是不可变的。不要给它任何标识，这样可以避免实体的维护工作，降低设计的复杂性。

例如，组成值对象的属性应该形成一个总体概念。例如，街道、城市和邮政编码不应该从Person对象中分离出去。但它们都是独立整体的一部分，这样可以使Person对象得到简化，同时也使得地址成为一个更加紧凑的值对象。

为了安全地共享对象，值对象必须具有不变性：它不能改变，除非把它整个替换掉。

复制和共享哪个开销低一些呢？这取决于实现环境。虽然复制会产生大量对象而阻塞系统，但是在分布式系统中进行共享会降低性能。

为了能够尽量利用共享带来的好吃，同时避免它的缺陷，只在以下情况中使用共享：
1. 当数据库中的存储空间和对象数量有严格限定时。
2. 当通信开销不高时（例如在一个中心服务器上）。
3. 当共享对象具有严格的不变性时。

在一些情况下考虑到系统性能，可能会允许值对象的改变。下面这些因素将倾向于在实现中允许更改：
1. 如果值经常被更改。
2. 如果对象的生成和删除的开销很大。
3. 如果替换（不是修改）会打破集群
4. 如果值没有太多的共享，或看共享没有提高集群，又或者一些其他技术方面的原因。

如果值的实现是允许更改的，那么它就不能被共享。不管您是否将值共享，都应该尽量将值对象设计成不可更改的。

服务

所谓服务，它强调与其他对象的联系。不像实体和值对象，服务完全是根据能够为客户做什么来定义的。服务往往代表一种行为，而不是一个实体，是一个动词而不是一个名词。服务可以有一个抽象的、有意图的定义，这与一个对象的定义有所不同。服务应该还有一个定义好的职责，它的职责和接口被定义为领域模型的一部分。操作名应该来自通用语言，如果通用语言中还没有这个操作名，则应该把它添加进去。调用的参数和返回的结果应该是领域对象。

一个优秀的服务具备3种特征：
1. 与领域概念相关的操作不是实体和值对象中固有的部分
2. 接口根据领域模型中的其他元素来定义。
3. 操作是无状态的。