DDD (Domain-driven design)，领域驱动设计，核心在领域。
什么是领域呢？
我们都知道写代码之前，首先需要梳理业务，然后再做系统设计，不可能让产品经理站在你的身后，一边告诉你业务需求，一边写代码，说一句话，响应写一行代码，我们可以把它称为“响应式编程”。
一般的，我们在写代码之前，会进行需求分析和方案设计。这一步最重要的就是把需求转换为能够落实的技术方案。而设计方案的时候，先要把需求涉及的业务边界搞清楚。
如果我们采用传统的三层架构，基于单体架构快速开发一个电商系统，可能很快就写完了，系统分层架构可能是这样：
然后，我们发现需求越来越多，于是加人呀，一大堆人进来开发同一个系统，由于只有水平的三层结构，导致模块间是耦合在一起的，很可能调整一个底层的dao或者service方法，就导致其他各个模块收到影响；另外，大家一起在一个项目里面写代码，似乎每天都在解决冲突，技术债务开始越来越多…
尝试引入微服务
于是，我们会想起拆分服务，搞成多个微服务，不同的同事在不同的服务上面开发，问题就解决了。
而拆分微服务的过程中，就需要区分业务边界，定义好业务领域的限界上下文。
领域就是一个范围，圈定了一个业务的边界。领域往往是业务的某一个部分，可以称为模块，例如电商系统的，商品模块，订单模块，用户模块，这些模块就是一个一个的领域，领域的关键是领域边界，能不能很好的区分边界，决定了领域模型构建的合理性，领域就是用于解决这个边界范围内的问题域的。
于是我们找到业务同事、产品同事，技术同事一起讨论了好几天，把系统的业务都梳理了一遍，按照高内聚、低耦合的原则，最终把大的系统划分成了几个领域，重新按照新的微服务架构梳理了整个系统的业务流程。然后就开始把单体系统重构为了微服务系统…
这一切看起来很顺利…
拆分完成之后，每个微服务仍旧是三层架构，经过了若干次需求迭代之后，我们惊奇的发现，拆分出来的微服务系统又开始变得越来越复杂了，另外，由于同事们把需求都按照事务脚本的形式填充到了Service层中，导致系统中出现了不少重复或者逻辑相似的代码，每次优化，都要修补很多地方，随着重复的代码越多，bug好像也越顽固，新来的那个同事表示，快要hold不住了…
问题：
- service不断膨胀，难以维护，找不到业务入口，只能通过rpc方法来查找入口
- service存在大量重复代码
项目负责人意识到，似乎，又得重新做一次拆分了…
聪明的团队，也许会在接收到新的需求之后，开始讨论会不会有新的领域，需不需要创建新的微服务来搞。但并不是所有的需求都会经过这样的思考过程，不知不觉中，微服务内部逻辑就开始变得复杂起来了。
最终，拆分后的微服务又变成了新的微单体，又得面临拆分的困境。
我们开始思考，微服务的问题出现在哪里了？
最终，我们发现，虽然微服务做了拆分，保证了微服务之间的解耦，但是微服务内部依然是典型的三层架构，而在互联网小步快跑，迭代试错的大环境下，开发同事接到需求，按照业务流程从头到尾就把代码填充到了三层架构中，最终导致微服务快速腐化。而目前互联网项目逐渐深入实体经济，业务日趋复杂，导致服务腐化的越来越快。
其实，我们在构建微服务的过程中，就已经用上了DDD的思想，只不过，并没有把DDD贯彻到整个项目的生命周期中。
除了拆分微服务的过程中需要考虑领域模型，我们在迭代需求的过程中，也需要不断的考虑，并且需要在系统中提供特定的DDD的项目结构，方便开发同事按照项目结构进行填充代码，避免走回三层架构的贫血模型的老路。
接下来，我们先来看看DDD的架构思想，如何让DDD在我们的项目中落地。