为什么需要DDD？
我们都知道随着技术的发展，架构也在不断的演变，从单机架构到分布式架构再到现在火热的微服务（现在更火热的应该是service mesh了 哈笑~）但是微服务也存在一些问题，微服务的粒度应该多大 ？ 微服务如何设计呢？ 微服务如何拆分 ？ 微服务边界在哪里 ？所以总结来说微服务的难点就是边界问题。而DDD就是解决了这个确定业务边界的问题，可见DDD并不是一种技术架构，而是一种划分业务领域范围的方法论。可以很好实现微服务内部和外部的”高内聚、低耦合”。
领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也称为概念模型、领域对象模型和分析对象模型。
DDD领域驱动设计
领域驱动设计，我们做开发中容易出现对一些功能归属模糊不清，区别于传统架构设计，ddd帮助做到清晰划分。
既面向技术也面向业务，从业务的角度来把握设计方案
4个特点：统一思想、明确分工、反映变化、边界分离。
4种模式：失血模式、贫血模式、充血模式、胀血模式。
失血模式：模型中只有简单的get set方法，是对一个实体最简单的封装，其他所有的业务行为由服务类来完成。
贫血模式：在失血模型基础之上聚合了业务领域行为，不关心数据持久化。
充血模式：在贫血模型基础上，负责数据的持久化。
胀血模式：service都不需要，所有的业务逻辑、数据存储都放到一个类中。
对于DDD来说，失血和胀血都是不合适的，充血模型依赖repository接口，与数据存储紧密相关，有破坏程序稳定性的风险。
建模方法：
- 用例分析法
- 四色建模法
- 事件风暴
- 本文标题： DDD学习笔记
- 文章作者： sherryriver（木木三可）
- 发布时间： 2020.12.10
- 本文链接： https://sherryriver.github.io/2020/12/10/DDD学习笔记/
- 许可协议： "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。