DDD学习记录（一）
Entity
由标识定义的对象被称作为实体（Entity）。当一个对象由其标识（而不是属性）区分时，那么在模型中应该主要通过标识来确定该对象的定义。使类的定义变得简单，并集中关注生命周期的连续性标识。定义一种区分对象的方式，这种方式与其形式和历史无关。
- 体育场的座位号。在进行座位预定程序设计时，如果每张票都有一个座位号，那么这个座位就是Entity，座位号就是它的标识。
- 如果是采用入场券形式入场，任何人可以随意选择座位，那么，这个时候座位就不是一个Entity。这种情况下，只有座位总数才是重要的。如果模型仍然把入场券和座位关联起来，那么它就是错误的。此时，座位不是Entity，不需要标识符
Value Object
用于描述领域的某个方面而本身没有概念标识的对象称为Value Object（值对象）。对于这些对象，被实例化后，我们只关心他是什么，不关心他是谁。
当我们只关心一个模型元素的属性时，应把它归类为Value Object。Value Object应该是不可变的。不要为它分配任何标识，而且不要把它设计成像Entity那样复杂。
我理解的Value Object 像是对象的一个模板，只关心它的属性框架，不需要具体到某一个。
Value Object的好处:
- 节省数据库空间、减少对象数量
- 通信开销低
- 共享的对象被严格的限制为不可变。
Service
所谓的Service，它强调的是与其他对象的关系。它在模型中是独立的，是作为接口提供的一种操作。它只是定义了能够为客户做什么。
好的Service特征：
- 与领域概念相关的操作不是Entity或Value Object的一个自然组成部分。
- 接口根据领域模型的其他元素定义的
- 操作是无状态的
当领域中的某个重要的过程或转换操作不是Entity或ValueObject的自然职责时，应该在模型中添加一个作为独立接口的操作，并将其声明为Service。定义接口时要使用模型语言，并且确保操作名称是ubiquitous Language（通用语言）。此外Service应该设计为无状态的。
Module(也称为Package)
Module应该是低耦合的，而Module内部应该是高内聚的。选择能够描述系统的Module，并使之包含一个内聚的概念集合。这里可以理解为我们代码上的包划分，划分的时候，尽可能的根据领域对象把合适的对象划分到一起。
- 除非真正有必要将代码分布到不同的服务器上，否则就把他们实现单一概念对象的所有代码放在同一个模块。
- 利用打包把领域层从其他代码中分离出来。否则，就尽可能让领域开发人员自由的决定领域对象的打包方式，以便支持他们的模型和设计选择。