在该章节里面有如下内容：
- 从战术的角度创建高效的面向对象的领域模型
- 介绍value objects, entities, domain services, modules ,通过这些为domain和行为建模
- 回顾生命周期模型：aggregate, factory, repository
- 新兴模式关于事件源和领域事件
Tactical patterns
ddd的作用是控制系统复杂度，确保领域模型简洁。模型用来表达模型的含义，关系，逻辑。
每个用于搭建框架的模块，都有自己单一的职责；在领域模型里面等价于entity或value object。不受生命周期中factory，repository的干扰。
可以使用组件，创建domain模型。
Patterns to Model Your Domain
以下模式代表问题域的策略和逻辑。表达了对象，模型规则，并将分析模型的细节绑定到代码实现模型。
如下介绍的是代码中的模型元素。
Entities
entity的概念是由身份定义，而不是属性。即使entity包含整个生命周期，它的属性可能改变。entity的责任是负责定义跟它行为类似的类。在代码里面，可以通过继承来实现这个类。（个人感觉，entities有点类似平时用的实体，或者实体的父类，不仅仅有属性，还有丰富的方法表示它的行为）
Value Objects
value objects为代表包含domain特性的元素或者概念；它们用来描述模型；用来描述模型里面的元素；它们不需要独特的身份。因为value objects 在模型中，没有概念上的认同，它们被定义为属性，这些属性决定了它的行为。value objects不需要身份，因为它经常在特定背景下跟其他的对象相关联。举个例子，有个order entity 使用value objects 代表order的address, items, courier information。它不需要特定的身份，它内容直接关联order。order的address如果不跟order关联 起来，完全没有意义。value objecs基于orders的属性，就像实体自带equal检查。
因为value objects根据他们的特性定义，value objects被认为一成不变的；也就是说，一旦被构造创建，它们将永远不会更改它的状态。一个好的例子就是money，不需要区分口袋里面钱的多少。不需要关注货币的身份，只需要关注它的值和它代表的含义。如果有人想跟你交换一个5$，事实仍旧拥有5$。当然，在现实生活中，钱可以拥有独特的身份id， 但是领域模型并没有影响真实的生活。相反，它是对它的抽象，旨在满足问题域内用例的需求。
Domain Service
Domain services封装domain的逻辑和概念，既不是entity，也不是value object。Domain services 既没有身份，也没有状态；它的职责是编排调度entity和value object的逻辑。
Modules
用它组织和封装相关概念(entities和value objects)。用来简化对大的domain models的理解。modules让开发者很快阅读，理解domain model，方便查找。(其实就是放entities和value objects的文件夹)
LifeCycle Patterns
这个模式用于创建，持久化 domain objects。
Aggregates
entities和value objects共同构成domain model，并满足不变性。在处理对象的大型互连关联时，通常难以确保对域对象执行操作时的一致性和并发性。
domain driven design 通过Aggregates 确保一致性和定义事务实时性。 大的models被分割成不变的部分，以及分为实体和价值对象的集合，这些实体和价值对象被视为概念整体。
多个aggregate通过id之间互相关联，既创建了关联，也避免了冗余不必要的大对象。
Factories
如果创建entity或者value object非常复杂，需要委托给factory的构造函数。factory确保所有的不变在domain object创建之前初始化完成。如果domain object很简单，没有什么特别的规则对于有效的构造函数，优先采用构造函数而不是factory。可以使用factories重复创建domain objects从持久存储里面。
Repositories
领域模型需要需要持久化方法。因为aggregate被视为自动单元，必须持久化通过完整的aggregate来更新。repository 是底层持久存储的抽象，允许创建模型，无需考虑架构层面的东西。repository是用来纠正和持久化aggregates的机制。
Emerging Patterns
Domain Events
domain events表示业务关注的，在问题域发生的一些事情。可以通过events去记录模型改变, 通过审计的方式。常用于aggregate root 的行为作用域aggregate root的周边。其他的aggregates 将听从这个events，并按照指示变化。
Event Sourcing
事件源是传统的持久层快照的一种当下流行的取代方式。替代了存储状态到数据库，存储事件能关联到状态。对状态的存储，增加了业务的可分析性。不仅仅知道当下entity的状态，而且可以知道state在过去时候的任意状态。storing events， not snapshots。
可以查询在任意时刻的domain model的状态，因为可以找到相关事件发生对状态的改变。
The Salient Points
