周末看到公司CTO徐昊老师在极客时间上的《如何使用Smart Domain实现DDD》的分享，真正体会到了什么是领域模型驱动开发， 模型和实现相一致。 随即按照Smart Domain的方法，用AB测试服务进行了练习，对领域模型和实现进行了重构。特此记录一下自己的一些理解。
Smart Domain
实践DDD中常见问题
徐昊老师在分享中指出，实践DDD中常见的一个问题是假设了同样的全局边界中的实体（aggregation root 和 entity）具有相同的生命周期（同时加载到内存或同时从内存中消失），而由于数据库和服务间远程调用存在，实体间的生命周期不都是同步的。为了在领域模型中屏蔽这种不同步，我们需要引入Service / Repository 等技术组件来帮助我们跨越生命周期完成一定的业务一致性逻辑，从而使得原本应该在领域概念中的业务逻辑外溢到到技术组件中，使得领域模型趋于贫血化。
理想的面向对象模型
有一组彼此互联并与领域概念相对应的对象模型。
有适当的抽象：
生命周期和实现细节被封装起来
持久化逻辑也是实现细节应该封装起来
什么是Smart Domain Pattern
* 一个纯面向对象的方法，不引入Service
* 模型被建模成一个对象连接的对象图
* 模型图可被直接映射成Restful API
* 领域层充当一个屏蔽实现细节的抽象层
* 实现概念模型、实现模型和API一致映射
以数据抽象行为
面向对象的一个重要设计思想是，以数据抽象行为。对象/数据是行为产生的结果，数据可以表示某个行为。
实体（Entity）由身份（Identity）、值（Value）和与其他对象的关联关系（Association）构成， 其中比较关键的是身份和关联关系。
实体可以很容易的映射成松散表示模型，Identity映射为URI， Value映射为内容， Association映射为链接。
关联关系可以作为一种抽象机制
关联关系是对生命周期抽象 - 不需要间接获取的内容为同生命周期，需要间接调用获取的内容为不同生命周期
关联关系是对行为的抽象 - 数据是行为产生的结果，通过关联关系获取的对象结果表征某一行为
模型中显示的将关联关系建模为抽象对象，则可以屏蔽对象之间的生命周期差异，并将合理的行为分配给关联关系对象进行封装。
默认间接异步获取
考虑到对象可能是通过数据库或远程调用加载，所以关联关系中方法获取数据应默认是间接且异步获取的，从而能很好屏蔽不同生命周期差异。这点让我想到了响应式类库Reactor中的[Mono和Flux](https://dimitr.im/difference-between-mono-and-flux)。
Mono和Flux是响应式开源库Reactor中两个基本的集合对象，Mono会返回0到1个对象，Flux则可返回多个对象。
利用Mono和Flux可以用异步非阻塞的流式访问和处理数据，个人觉得这点与关联关系中法获取数据应默认是间接且异步十分契合。
Smart Domain建模步骤
1. 基于对象为行为的结果寻找实体
2. 寻找实体间的关联关系
3. 将关联关系显示建模为抽象对象
4. 为对象（包括关联关系）分配职责
Smart Domain实现步骤
1. 依据领域模型将关联关系实现为接口
2. 将实体实现为类分配身份和关联关系接口
3. 为关联关系接口提供具体实现
4. 将领域模型映射为Restful API
分层架构
Smart Domain Pattern中仅分为两个大层和一个亚层：
领域层 - 定义实体和实体间关联关系抽象接口
集成层 - 作为领域层的亚层，提供关联关系接口实现
API层 - 向外暴露基于领域层对象关系图得到的Restful API
AB测试服务
运营在上新功能时一般都需要通过AB实验收集新老版本的用户数据，来对比新功能是否符合预期。
完整的AB实验链路由实验管理、用户圈定、用户分组、数据收集、数据分析几大部分构成。
实验管理 - 管理实验配置和生命周期
用户圈定 - 具有相似属性的人群，往往具有相似的行为模式，所以圈定具有相似属性的人群来进行实验，能够提高实验结果可信度
用户分组 - 实验过程中将用户随机分配到实验组或对照组，并且整个实验过程中分组结果应该保持一致
数据收集 - 数据收集包括用户的界面操作行为（通过埋点收集）和用户业务行为数据（通过业务数据统计收集）
数据分析 - 分析处理收集到的实验数据，得到不同组的对比指标，指导实验效果
商用或开源AB测试解决方案，往往提供大而全的完整解决方案，不利于与已有系统能力集成和复用。一般企业往往有自己的卖点和数据处理能力，仅需引入实验合分组管理能力就可以实现完整的AB测试服务解决方案。
上下文介绍
AB实验服务管理AB实验生命周期
DMP根据用户属性或行为为用户添加标签，实验圈定相似属性的人群来进行实验统计，增加实验可信度
AB实验服务根据用户标签判断用户是否进入实验
进入实验的用户随机分配实验组，并记录其分组结果，保证实验过程中用户分组结果固定
实验过程中，业务系统通过AB实验获取用户分组结果，根据分组生效不同配置
APP根据后端不同配置加载展示不同内容，通过埋点上报事件
DMP结合埋点和业务数据，分析实验结果
通过Smart Domain对AB实验服务建模
1. 根据行为结果寻找实体
Experiment （实验）- 作为聚合根聚合实验相关逻辑
Bucket（分组）- 每个实验包含多个实验分组
MemberCriteriaCondition（人群圈定条件）- 用户进入实验判定条件
MemberCriteriaResult （人群圈定结果）- 依据人群圈定条件得到的人群圈定结果
Assignment（分组结果）- 每个用户会在每个实验中会有一个分组结果
2. 寻找实体间的关联关系
得到如下模型图
3. 将关联关系建模为抽象对象
4. 为对象（包括关联关系）分配职责
AB实验中处理对象加载和保存的职责外比较重要的一个职责是为用户计算分组，分组主要逻辑是判断用户是否满足圈人条件，满足圈人条件则实验分组中随机分配一个。
按照GRASP中信息专家模式，职责应该分配给拥有实现职责所需要的所有信息的对象。计算分组需要依赖圈人条件、圈人结果、实验分组，同时拥有这三个信息的对象是Experiment，所以该职责分配给Experiment （assign方法）。 其中随机分配到某个分组进需要实验分组的信息，该职责可以委托给关联关系对象Buckts（assignByCustomerId方法）。
至此我们得到如下最终的AB实验领域模型：
实现
得到了上面的领域模型，实现过程相对比较简单，按照上文中Smart Domain实现步骤进行即可，部分实现代码已上传到GitHub上GitHub - pc-dong/ab-testing。
总结
Smart Domain Pattern 将关联关系显式建模为抽象对象，对象关联数据访问默认认为是间接异步的，统一了因为数据库访问或远程调用带来的生命周期差异；可以将职责合理的分配给对象（包括关联关系）而不会引入Service等额外技术组件；分层简单真正实现模型、实现相一致。
这里附上徐昊老师的分享的Demo： https://github.com/Re-engineering-Domain-Driven-Design/Accounting，大家有兴趣可以一同学习。
