之前看过领域设计一本书，还写过读书心得，从理论上介绍了领域设计的一些思路和方法论。
https://www.jianshu.com/p/712a49baf468
这里更多的是从实践的角度去落地领域设计的方法。
从领域设计到实践本人总结了几个阶段：
- 构建领域词汇表
- 事件风暴会议
- 业务拆分
- 模型设计
构建领域词汇表：解决沟通障碍
目标就是统一领域专家，产品经理，业务开发，测试等多个岗位的语言，
减少沟通的障碍，便于理解。
通常为了方便程序员之间沟通，领域词汇表会中英两份，英文词汇还会对应代码中的Class类名，成员变量名。
比如，一个机器学习系统，
常见的领域词汇表：
数据集 -- dataset
模型 -- model
机器学习 -- MachineLearning
训练 -- train
预测 -- predict
特征 -- feature
数据清洗 -- Data cleaning
致性检查 -- consistency check
估算 -- estimation
整例 / 变量删除 -- casewise / variable deletion
成对删除 - pairwise deletion
探索性分析 -- EDA
再比如，一个下单系统
商家/订单/用户/地址/商品 等等
如果系统是0-1的阶段，领域词汇可以由领域专家来节点，表达和含义。
如果系统已经过了0-1的阶段，建议回顾历史系统，也就是直接进入到领域事件的梳理，就是下一个阶段。
事件风暴会议：拆分事件对象关系条件
围绕事件不断的拓展业务内容。
比如，针对一个订单系统的事件风暴，
订单系统中有很多事件，如果已经是一个成熟系统了，可以直接看下代码中的ENUM定义，
已经接单，已经就绪，已经下单，已经派送，已经送达。围绕一个“已经下单”的领域事件，领域风暴会议可能会画出如下一张图。
比如：
- 事件：下单事件
- 围绕事件，产生了领域的对象（领域词汇对应的对象）：
- 用户
- 地址
- 商店
- 订单
- 商品
- 不断把领域词汇聚集起来，形成聚合根，比如商品
在一个成熟的团队中，领域风暴事件中每个颜色代表一层含义。比如上面这个示意图中。
- 红色： 代表中心的领域事件
- 蓝色： 代表事件处罚的条件
- 黄色： 代表领域对象
- 紫色： 代表聚合根
这个颜色的含义，一般来自团队之间的磨合产生的习惯。非必须。
如果一个系统是0-1，怎么组织一次事件风暴会议，
一个常用的手段是利用主流程来拆分。
比如一个机器学习系统：
导入数据 --> 数据加工 --> 触发学习 --> 学习完成 --> 模型评估 --> 模型发布。
比如一个订单系统：
添加商品 --> 下单 --> 商家接单 --> 商家发货 --> 骑手接单--> 骑手送达 -->确认收货。
业务拆分：DDD到微服务
事件风暴会结合每个事件，不断的拆分出领域对象，
然后讲相关的对象聚合在一起，区分行为。但是到具体的服务设计之后。
会再划分出子领域，每个子领域对应一个或者一组相关的微服务。
不同组的微服务之间有明确的界限来划分自己的指责，同时多个微服务构成了一个大的系统。
比如，还是之前的下单的业务场景。
“下单”是一个子领域
围绕下单这个主题，会形成一个核心的主题域处理下单
但是围绕下单，还有用户的操作，商家的操作相关操作作为支撑。
所以拆分关系是：
绿色是这个子领域的一个核心主题服务，灰色是这个子领域的支撑服务，微服务的设计
- 用户 可作为一个微服务，支撑订单这个核心服务
- 商家 可作为一个微服务，支撑订单这个核心服务
- 订单 可作为一个微服务
贫血模型和充血模型设计：表和服务接口
领域对象的设计，先设计核心层，核心层结束后
针对持久化层设计DO，
针对传输对象设计DTO，
针对业务表现层设计VO，
设计核心领域对象的时候，可以用贫血模型，也可以用充血模型。
比如贫血模型设计订单这个领域对象。
“贫血模型设计 ” ： 数据逻辑分开，数据即领域，service对应领域对象的行为，对象关系的封装。
- 商家DO
- 商家id
- 商家name
- 商品id
- 商品DO
- 商品id
- 商品name
- 商品价格 price
- 商家Service
- 商品Service
- get商品，从商家service和商品service分别获取两个entity，做组装
“充血模型设计” ：增加一个Domain层，把数据和方法封装为Domain
- 商品Object
- 商品id
- 商品name
- 商家id
- 商品DAO
- 商品Domain： 数值 + 方法，DAO的调用 + 逻辑的组装
- 商品service
- getEntity，Domain里面获取所有需要的值
tips：很多人会问到贫血模型和充血模型有什么差别，用自己的理解方式，本质是一样的，贫血模型的封装性体现在service层，而充血模型多了一个domain层，领域的封装性放到了domain层而已。
当然大家也可以用网上“面向面试”的回答方式：贫血模型数据和service分离，充血模型数据和service统一。
补充：微服务的治理
这里不是重点，只提一下和领域设计相关的是多个服务之间的解耦，必要的两个技术是：
- 消息队列：一个订单事件再多个服务之间流转，通常是通过订单消息来通知各个服务。
- 注册中心：微服务之间通常不感知哪个物理服务上线和下线，通常通过注册和发现来调用具体的服务。
消息对接和注册中心这里不过多介绍了，如果不了解还请查阅相关资料。
