领域驱动设计-软件中所表示的模型
图片.png
模式：ENTITY（又称为REFERENCE OBJECT）
用来表示某种具有连续性和标识的事物（可以跟踪它所经历的不同状态，甚至可以跨不同的实现跟踪它）
当一个对象由其标识（而不是属性）区分时，那么在模型中应该主要通过标识来确定该对象的定义。
在定义标识操作时，要确保这种操作为每个对象生成唯一的结果
模型必须定义出“符合什么条件才算是相同的事物”
ENTITY最基本的职责是确保连续性，以便使其行为更清楚且可预测
设计标识操作
每个ENTITY都必须有一种建立标识的操作方式，以便与其他对象区分开，即使这些对象与它具有相同的描述属性。不管系统是如何定义的，都必须确保标识属性在系统中是唯一的，即使是在分布式系统中，或者对象已被归档，也必须确保标识的唯一性
ID通常是由系统自动生成的。
当自动生成ID时，用户可能永远不需要看到它。ID可能只是在内部需要。
ddd中的ENTITY在一些地方又被称之为DO(DoMain Object)
模式：VALUE OBJECT
很多对象没有概念上的标识，它们描述了一个事物的某种特征
- VO可以是其他对象的集合。
- VO可以引用Entity。
- VO经常作为参数在对象之间传递消息。
- VO所包含的属性应该是一个整体概念
- 由于没有标识，两个VO间的双向关联是没有意义的
- VO的引用与共享：
当一个对象将它的一个属性(VO)作为参数或返回值传递给另一个对象时，当我们修改一个对象的这个属性，会导致另一个对象的属性值跟着变化。
“流浪”的对象会发生任何事情，这种情况下可以通过传递一个不变对象或一个副本来解决
模式：SERVICE
重要的领域操作，一些活动或动作不是Entity和VO的自然职责时，声明一个SERVICE作为独立接口的操作。所谓SERVICE，强调的是与其他对象的关系，它应该是一个“动词”而非“名词”，因此，SERVICE应是无状态的。
其他功能：控制领域层中的接口的粒度，并且避免客户端与ENTITY和VALUE OBJECT耦合
- FACADE（存疑）：
FACADE(外观)是一种设计模式，即外观模式，将一系列复杂的类包装成一个简单的封闭接口。
在一个领域对象与外部资源间直接建立一个接口是很别扭的，我们可以利用FACADE将外部SERVICE包装起来。
对某个领域的SERVICE进行组装编排，提供给其他领域的SERVICE进行调用？
模式：MODULE（也称为PACKAGE）
MODULE之间应该是低耦合的，而在MODULE的内部则是高内聚的。
MODULE并不仅仅是代码的划分，而且也是概念的划分。
MODULE为人们提供了两种观察模型的方式，
一是可以在MODULE中查看细节，而不会被整个模型淹没，
二是观察MODULE之间的关系，而不考虑其内部细节
MODULE的选择应该取决于被划分到模块中的对象的意义。当你将一些类放到MODULE中时，相当于告诉下一位看到你的设计的开发人员要把这些类放在一起考虑。
MODULE的名称应该是UBIQUITOUS LANGUAGE中的术语。MODULE及其名称应反映出领域的深层知识。
MODULE需要与模型的其他部分一同演变。MODULE的重构必须与模型和代码一起进行。
