DDD 的基本开发过程
捕获行为需求，也就是传统软件工程里的“获取需求”。这一步，我们要识别需求里有哪些流程、哪些功能，每个功能由什么人操作，会产生什么结果。
进行领域建模，也就是通过建立领域模型，把需求里的主要业务知识描述清楚。DDD 的领域模型，大体上相当于传统软件工程中的分析模型
架构设计，包括进程间和进程内的架构。比如说微服务设计、中台设计都属于进程间架构。而 DDD 分层架构，通常说的是进程内架构
根据领域模型进行数据库设计，最后是代码实现
03 事件风暴
事件风暴的第一步：识别领域事件
所谓领域事件，就是在业务过程中，业务人员要关注的那些已经发生的事儿。比方说，对于电子商务系统，订单已提交、商品已签收等等，都是领域事件。实际上，领域事件表示的是，业务流程中每个步骤引发的结果
识别“项目管理”流程的领域事件
04 事件风暴
事件风暴第二步：识别命令
命令（command），就是引发领域事件的操作，我们可以通过分析领域事件得到。除了识别出命令本身以外，我们通常还要识别出谁执行的命令，以及为了执行命令我们要查询出什么数据。
事件风暴第三步：识别领域名词
这里说的领域名词，是从命令、领域事件、执行者、查询数据里找到的名词性概念。例如，对于签订合同这个命令而言，受到影响的名词性概念是“合同”；类似地，对于合同已签订这个领域事件，是由于“合同”这个名词性概念的状态变化所导致的
再谈事件风暴的作用
这是因为，在这一步里识别出的名词，虽然很可能就是领域对象，但也未必。一个名词有可能只是一个对象充当的角色，或者对象的属性，还有些名词需要经过合并或拆解后，才是合理的领域对象，而这些需要等到领域建模时才能真正搞清楚。
05 领域建模实践
领域建模中的一些基本概念
领域建模主要有两个目的：
将知识可视化，准确、深刻地反映领域知识，并且在业务和技术人员之间达成一致；
指导系统的设计和编码，也就是说，领域模型应该能够比较容易地转化成数据库模式和代码实现。
什么是领域对象呢？我们系统中要处理的各种“事物”就是领域对象。比如说项目、员工、账户等等。这些对象都反映了名词性的概念
DDD 中将领域对象又分成实体（entity）和值对象（value object）
初步识别实体
识别“一对一”关联
识别“一对多”关联
识别“自关联”
06 领域建模其他技巧
划分模块
解决这一问题的方法就是“模块化”。也就是说，把模型中的业务概念组织成若干高内聚的模块（module），而模块之间尽量低耦合
把模型分成了 4 个模块，分别是租户管理、组织管理、项目管理和工时管理
完善业务规则
建立词汇表
主要是有两个作用。首先，我们需要通过词汇表来规范领域模型中的词汇。同一个词，可能会在领域模型中出现多次，时间久了，就可能不一致，因此需要进一步规范。
第二，是可以用于后续编程中的命名。按照 DDD 的要求，程序中的各种命名也需要统一，并且需要与领域模型中保持一致。我们会在词汇表中列出英文全称和缩写，以达到这个目的。
07 DDD 领域模型与传统方法的不同之处
DDD 的领域模型则是业务视角（原来的分析模型）和技术视角（原来的设计模型）的交集。它反映了业务人员和技术人员的共识
领域模型与统一语言
统一语言包含了两个层面的含义：一是业务和技术人员之间的语言是统一的，二是开发团队内部各角色之间的语言是统一的。最终结果就是每一行代码都能对应到统一语言，从而与业务保持一致
09 分层架构：怎样逃离“大泥球”
分离领域
DDD 对代码架构最核心的要求就是要将领域层分离出来。领域层封装了领域数据和逻辑，我们前面的领域模型所对应的代码，主要就体现在领域层。只有将领域层独立出来，才能保证与领域模型的一致，也才能让领域层独立演化
给领域一个“门面”
领域层封装的逻辑通常是细粒度的，并不适合直接作为 API 暴露给外部。另外，还有一些不属于领域层的横切关注点，比如像事务控制，应该单独处理。所以，我们往往要在领域层外面再加一层，DDD 和六边形架构都将这一层称为 Application，也就是应用层。
应用层本身并不包含领域逻辑，而是对领域层中的逻辑进行封装和编排。
用“适配器”处理输入输出
我们的系统要和外界打交道，可以通过不同技术来实现，比如 Restful API、 RPC，以及传统的 Web 页面等等
适配器会把和具体技术有关的请求，翻译成和技术无关的请求，再调用应用层来实现业务功能；在接收到应用层的返回值以后，又转化成技术相关的响应，返回给外界。也就是说适配器层屏蔽了输入输出技术的差异，从而使应用层与具体技术无关，这样就达到了分离关注点的目的。
用“适配器”处理数据持久化
10 贫血还是充血
贫血模型，英文叫做 Anemic Domain Model ，是 Martin Fowler 在 2003 年提出的，恰好在《DDD》这本书写作的同一年。贫血模型指的是领域对象中只有数据，没有行为，由于过于单薄，就好像人贫血了一样，显得不太健康。这种风格违背了面向对象的原则
Rich Domain Mode，可以译作“富领域模型”，也就是领域对象里既包含数据，也包含行为
DDD 强调，在代码编写阶段，如果发现模型的问题，要及时修改模型，始终保持代码和模型的一致
此时实现类impl仍然在适配器层adapter
11 创建领域对象 实现领域逻辑
“领域服务”（Domain Service）模式
12 怎样更加面向对象
