领域驱动设计

基本元素

导航图

Entity

很多对象不是通过他们的属性定义的，而是通过连续性和标识定义的。

举例：
一个人有一个标识，这个标识会陪伴他走完这一生。他的名字可能改变，财务关系可能改变，没有哪个属性时一生不变的，但标识却是永久的。

连续性：一些对象主要不是由它们的属性定义的，它们实际上表示了一条“标识线”，这条线跨越时间，而且常常经历多种不同的表示。

实体的概念： 一种贯穿整个生命周期（甚至经历多种形式）的抽象的连续性。

标识是Entity的一个微妙的、有意义的属性，我们是不能把它交给语言的自动特性来处理的。（如Java中的==标识符，内存对比）

模型必须定义出符合什么条件才算是相同的事物。

示例：
体育场座位预订，如果每张票都有一个座位号，则座位是Entity；如果票采用入场券的形式，观众可以任意挑选座位，则座位不是Entity。

考虑ID：
有时ID只是内部需要，用户可能永远不需要看到它。比如检索两个同名联系人，用户可以通过地址、公司等属性区分他们。
用户需要看到ID的场景：快递单号。

Value Object

用于描述领域的某个方面而本身没有概念标识的对象称为Value Object。我们只关心它是什么，不关心它是谁。

• Value Object可以是其他对象的集合；
• Value Object可以引用Entity；
• Value Object经常作为参数在对象之间传递信息。

当我们只关心一个模型元素的属性时，应把它归类为Value Object。

我们应该使这个模型元素能够表示出其属性的意义，并为它提供相关功能。

Value Object应当是不可变的。

不要为它分配任何标识，而且不要把它设计成像Entity那么复杂。

Value Object的双向关联没有任何意义，请尽量清除Value Object之间的双向关联。

Service

Service是一系列操作，无状态，通常以动词命名。

所谓Service，它强调的是与其他对象的关系。与Entity和Value Object不同，它只是定义了能够为客户做什么。Service往往是以一个活动来命名，而不是一个Entity来命名，也就是说，它是动词而不是名词。

各层Service的区别：

细粒度的领域对象可能会把领域层的知识泄漏到应用层中。一种解决方法是引入领域层服务。

Service访问：可以用单例模式。

Aggregate

Aggregate（聚合）概念是为了管理领域对象的生命周期而引出的。另外两个所需的概念为：Factory和Repositor