但也会带来很多开发与运维上的负担。用DDD（领域驱动设计） 的思想去指导微服务的实践则成为比较好的方案。
什么是 DDD 呢？DDD 与微服务之间到底有着什么样的联系？
DDD 是一种在面向高度复杂的软件系统时，关于如何去建模的方法论，它的关键点是根据系统的复杂程度建立合适的模型。
DDD 方法论在系统建模过程中，可以为团队中的各个角色提供一套“统一语言”，避免组件划分过程中的边界错位，完成领域图预演、需求分析、架构模型、代码模型、测试等工作。
“统一语言”的概念在 DDD 中极为重要，因为在一个系统的构建过程中，往往业务人员关注的是业务架构，而技术人员则关注系统架构的表述方式。
这导致在将业务架构映射到系统架构的时候，需要经过一层“翻译”工作，使工作变得复杂、低效。
在 DDD 中，只要使用一个“统一语言”，就可以直接将业务架构与系统架构绑定，不需要进一步去翻译，增强系统对业务的响应速度。
DDD“领域驱动设计”中的“领域”一词指的是要实现的软件系统所要解决的实际问题所处的整个领域范围，它不仅包括系统架构的相关问题，还涉及到系统所支持的业务等内容，但它是与具体的开发技术无关的。
也就是说 DDD 关注的是要构建的系统中，关于所要解决的问题的业务、流程和数据等内容是如何工作的，在这些东西理清之后，DDD 去构建出一个模型，接着再去选择具体的实现技术。
DDD 强调的是解耦具体实现技术，所以它可以迅速梳理核心业务逻辑。
DDD领域设计的过程如下：
在设计和实现一个系统的时候，这个系统所要处理问题的领域专家和开发人员以一套统一语言进行协作，共同完成该领域模型的构建，在这个过程中，业务架构和系统架构等问题都得到了解决，之后将领域模型中关于系统架构的主体映射为实现代码，完成系统的实现落地。
用什么方式去做领域模型的构建，方法是多样的，Event Storming（事件风暴），成为了一种经典的 DDD 落地模式。
理解了 DDD 的核心理念，就知道它和微服务的关系了。
DDD 的本质是一种软件设计方法，而微服务架构是具体的实现方式。
微服务架构虽好，但并没有给出如何对复杂系统进行分解的具体方法论，而 DDD 正好就是解决方案。
