第一部分
简介：
简单来说，DDD 的本质是一种软件设计方法，而微服务架构是具体的实现方式。微服务架构虽好，但是他并没有给出如何对复杂系统进行分解的具体方法论
第一部分
简介：
简单来说，DDD 的本质是一种软件设计方法，而微服务架构是具体的实现方式。微服务架构虽好，但是他并没有给出如何对复杂系统进行分解的具体方法论，而 DDD 正好就是解决方案。
DDD 强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是脱离领域模型来谈微服务设计。
中台本质是领域模型，微服务是领域模型的系统落地，DDD 是一种设计思想，它可以同时指导中台领域建模型和微服务设计，这就是 DDD、中台和微服务的铁三角关系。
如何学好 DDD ：
第 1 步：理解 DDD 的核心知识体系和设计思想；
第 2 步：和项目团队一起用事件风暴方法构建领域模型；
第 3 步：根据领域模型和正确的微服务设计方法亲自动手设计几个微服务（实战）。
===================我是分割线=====================
第二部分
DDD要解决什么问题：
- 业务人员跟技术人员沟通的问题。
技术人员可能会把某个概念理解偏了，结果费了九牛二虎之力写出来的代码，验收的时候才发现，代码实现的效果压根不是人家想要的。
DDD要求大家（业务领域专家和技术人员）都使用同一套术语，别再说xx表xx字段（那些是技术实现），也不要把定好的术语口头上改成自己理解术的语。 - 代码质量问题。
这里的代码质量不是指代码是否规范，而是说代码是否如实的实现了业务，业务逻辑是否清晰。业务术语，业务规则，业务流程在代码里是否有清晰的对应关系。
如果有新的小伙伴加入，要改一个需求:
a) 他能否直接通过已有的代码就能把业务梳理清楚，并清楚地知道需要改哪些地方。
b) 而且改好了之后，确信自己改的地方不会影响其他人的代码。
DDD的核心思想: 封装
从业务角度进行领域的划分、聚合的隔离，即业务的封装，聚合是业务的最小单元，具有原子性特征，聚合之间与子领域之间一样，通过协作方式（如，消息）来实现业务，以此来实现高内聚、低耦合的设计原则（P.S 只有业务内聚才能实现真正的高内聚）
DDD好处：
- 封装即是隔离，隔离与外部的交互，好处当然不言而喻——低耦合，使重构变得安全、容易，随时拆分为独立服务，等等。
- 很好的解决了业务人员与技术人员的沟通问题和高内聚低耦合的开发和架构演进问题
DDD坏处：
将数据不一致的影响面进一步放大，由微服务级别放大到微服务内的聚合级别。
