DDD
贫血失忆症
使用MVC的设计，业务逻辑通常是『面向过程』地写在service层。
我们定义的数据结构体顶多算一个数据载体，没有任何的行为。
时间长了，载体的service方法会散落在各个地方。
设计领域模型的一般步骤
- 根据需求划分出初步的领域和界限上下文，以及上下文之间的关系
- 分析每个上下文的内部，识别出哪些是实体，哪些是值对象
- 对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根
- 为聚合根设计仓储，并思考实体或值对象的创建方式
- 在工程中实践领域模型，并在实践中检验模型合理性，推倒模型不足的地方并重构
界限上下文
聊概念太难，这更好理解：
每个界限上下文应该拥有一个独立代码仓库。
一个团队应在一个界限上下文中工作。
一个团多可能工作在多个界限上下文。
一个界限上下文里不能有多个团队。
其他团队想改你的界限上下文，只能通过接口。
都叫『保单』，在承保上下文，审核上下文，理赔上下文 中有不同的定义。
1、不应该定义到一起，揉成一个四不像。应该在不同的上下文有自己的定义。
2、不需要起名叫承保保单、理赔保单。只需要在不同的上下文区分他们。他们就叫『保单』
License
Adopting CC BY-NC-SA 4.0 License Agreement
Share
