什么是DDD？
1、三个项目
至少20年前，一些顶尖的软件设计人员就已经认识到领域建模和设计的 重要性，但令人惊讶的是，这么长时间以来几乎没有人写出点什么，告诉 大家应该要哪些工作或如何去做。尽管这些工作还没有被清楚的表述出来， 但一种新的思潮已经形成，它像一股暗流一样在对象社区中涌动，我把这种 思潮称为领域驱动设计(Domain-Driven Design) 过去10年中，我在几个业务和技术领域开发了一些复杂的系统。我在设计 和开发过程中尝试了一些最佳实践，它们都是面向对象开发高手用过的领先 技术。有些项目非常成功，但有几个项目却失败了。成功的项目有一个共同 的特征，那就是都有一个丰富的领域模型，这个模型在迭代设计的过程中不 断演变，而且成为项目不可分割的一部分。
2、一种思潮
技术主动理解业务，业务如何运行，程序就如何构建。 让不怎么使用技术语言的领域专家一起参与软件建设
系统老化是谁的锅？
你和大神代码的差距在哪？
一、 以下列举一个方案
二、DDD改造后：
1）动手改造第一步：拆解出实体、和值对象，将贫血实体改造成充血实体，让实体与值对象改造为聚合对象；抽象出仓库，封装数据库的一些增删改查的操作逻辑，不依赖于某个具体的ORM框架，让具体实现类去承载具体哪一种的ORM框架实现。
2）动手改造第二步，增加防腐层，针对第三方服务抽象出通用的业务操作，让具体的实现类处理具体的业务逻辑，而对外围调用方来说，不需要关心你调用的具体逻辑，只关注调用的结果，针对结果能够做到统一的处理。
3）DDD改造第三步，针对第三方组件的调用（例如MQ），也可以利用防腐层的实现思想，隔离对第三方组件调用的具体逻辑，其实就是利用依赖倒转原则的思想，让我们的业务依赖于接口，而不依赖于具体实现。
4）DDD改造第四步，用领域服务封装多实体逻辑。
5）DDD最终改造后的方案：
通过以上项目的改造 ，那DDD架构到底是什么样的？
DDD四层架构
“DDD”VS DDD 的区别
所谓的“DDD”其实是Data Driven Design数据驱动设计，传统的MVC架构就是如此，以业务构建数据表，并划分出具体的微服务，从业务角度来看，我们的技术层级是比较清晰的，但是我们的业务逻辑边界是混乱的，不同微服务之间可能需要互相调用，拼装业务数据，才能实现我们某一个微服务下单一请求的处理。
而我们的DDD（Domain Driven Design）领域驱动设计，通过实体、值对象聚合为一个领域服务，区分出明显的限界上下文，只需要聚合不同的领域服务，即可实现用户不同的请求操作。
DDD带来的挑战与机会
