01 | 领域驱动设计：微服务设计为什么要选择DDD？

01 | 领域驱动设计：微服务设计为什么要选择DDD？

软件架构模式的演进在进入今天的主题之前，我们先来了解下背景。
我们知道，这些年来随着设备和新技术的发展，软件的架构模式发生了很大的变化。软件架构模式大体来说经历了从单机、集中式到分布式微服务架构三个阶段的演进。随着分布式技术的快速兴起，我们已经进入到了微服务架构时代。我们先来分析一下软件架构模式演进的三个阶段。

第一阶段是单机架构：采用面向过程的设计方法，系统包括客户端 UI 层和数据库两层，采用 C/S 架构模式，整个系统围绕数据库驱动设计和开发，并且总是从设计数据库和字段开始。

第二阶段是集中式架构：采用面向对象的设计方法，系统包括业务接入层、业务逻辑层和数据库层，采用经典的三层架构，也有部分应用采用传统的 SOA 架构。这种架构容易使系统变得臃肿，可扩展性和弹性伸缩性差。

第三阶段是分布式微服务架构：随着微服务架构理念的提出，集中式架构正向分布式微服务架构演进。微服务架构可以很好地实现应用之间的解耦，解决单体应用扩展性和弹性伸缩能力不足的问题。

我们知道，在单机和集中式架构时代，系统分析、设计和开发往往是独立、分阶段割裂进行的。比如，在系统建设过程中，我们经常会看到这样的情形：A 负责提出需求，B 负责需求分析，C 负责系统设计，D 负责代码实现，这样的流程很长，经手的人也很多，很容易导致信息丢失。最后，就很容易导致需求、设计与代码实现的不一致，往往到了软件上线后，我们才发现很多功能并不是自己想要的，或者做出来的功能跟自己提出的需求偏差太大。而且在单机和集中式架构这两种模式下，软件无法快速响应需求和业务的迅速变化，最终错失发展良机。此时，分布式微服务的出现就有点恰逢其时的意思了。

微服务设计和拆分的困境

那进入微服务架构时代以后，微服务确实也解决了原来采用集中式架构的单体应用的很多问题，比如扩展性、弹性伸缩能力、小规模团队的敏捷开发等等。但在看到这些好处的同时，微服务实践过程中也产生了不少的争论和疑惑：微服务的粒度应该多大呀？微服务到底应该如何拆分和设计呢？微服务的边界应该在哪里？可以说，很久以来都没有一套系统的理论和方法可以指导微服务的拆分，包括微服务架构模式的提出者 Martin Fowler 在提出微服务架构的时候，也没有告诉我们究竟应该如何拆分微服务。于是，在这段较长的时间里，就有不少人对微服务的理解产生了一些曲解。

于是，在这段较长的时间里，就有不少人对微服务的理解产生了一些曲解。有人认为：“微服务很简单，不过就是把原来一个单体包拆分为多个部署包，或者将原来的单体应用架构替换为一套支持微服务架构的技术框架，就算是微服务了。” 还有人说：“微服务嘛，就是要微要小，拆得越小效果越好。”但我想，这两年，你在技术圈中一定听说过一些项目因为前期微服务拆分过度，导致项目复杂度过高，无法上线和运维。综合来看，我认为微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。那如何确定，是否有相关理论或知识体系支持呢？在回答这些问题之前，我们先来了解一下领域驱动设计与微服务的前世今生。2004 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design –Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。但 DDD 提出后在软件开发领域一直都是“雷声大，雨点小”！直到 Martin Fowler 提出微服务架构，DDD 才真正迎来了自己的时代。有些熟悉 DDD 设计方法的软件工程师在进行微服务设计时，发现可以利用 DDD 设计方法来建立领域模型，划分领域边界，再根据这些领域边界从业务视角来划分微服务边界。而按照 DDD 方法设计出的微服务的业务和应用边界都非常合理，可以很好地实现微服务内部和外部的“高内聚、低耦合”。于是越来越多的人开始把 DDD 作为微服务设计的指导思想。现在，很多大型互联网企业已经将 DDD 设计方法作为微服务的主流设计方法了。DDD 也从过去“雷声大，雨点小”，开始真正火爆起来。

为什么 DDD 适合微服务？

“众里寻他千百度。蓦然回首，那人却在灯火阑珊处。”在经历了多年的迷茫和争论后，微服务终于寻到了他的心上人。那 DDD 到底是何方神圣，拥有什么神器呢？DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是架构，而

DDD 包括战略设计和战术设计两部分。

战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。我们不妨来看看 DDD 是如何进行战略设计的。DDD 战略设计会建立领域模型，领域模型可以用于指导微服务的设计和拆分。事件风暴是建立领域模型的主要方法，它是一个从发散到收敛的过程。它通常采用用例分析、场景分析和用户旅程分析，尽可能全面不遗漏地分解业务领域，并梳理领域对象之间的关系，这是一个发散的过程。事件风暴过程会产生很多的实体、命令、事件等领域对象，我们将这些领域对象从不同的维度进行聚类，形成如聚合、限界上下文等边界，建立领域模型，这就是一个收敛的过程。

我们可以用三步来划定领域模型和微服务的边界。

第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。

第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。

第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。有了这两层边界，微服务的设计就不是什么难事了。在战略设计中我们建立了领域模型，划定了业务领域的边界，建立了通用语言和限界上下文，确定了领域模型中各个领域对象的关系。到这儿，业务端领域模型的设计工作基本就完成了，这个过程同时也基本确定了应用端的微服务边界。在从业务模型向微服务落地的过程中，也就是从战略设计向战术设计的实施过程中，我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时，系统架构也会同时发生调整，并同步建立新的映射关系。

DDD 与微服务的关系
有了上面的讲解，现在我们不妨再次总结下 DDD 与微服务的关系。DDD 是一种架构设计方法，微服务是一种架构风格，两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。总结今天我们主要讨论了微服务设计和拆分的难题。通过 DDD 战略设计可以建立领域模型，划定领域边界，解决微服务设计过程中，边界难以划定的难题。如果你的业务焦点在领域和领域逻辑，那么你就可以选择 DDD 作为微服务的设计方法！

更关键的一点是，DDD 不仅可以用于微服务设计，还可以很好地应用于企业中台的设计。如果你的企业正在做中台转型，DDD 将会是一把利器，它可以帮你建立一个非常好的企业级中台业务模型。有关这点你还会在后面的文章中见到详解。除此之外，DDD 战术设计对设计和开发人员的要求相对较高，实现起来相对复杂。不同企业的研发管理能力和个人开发水平可能会存在差异。尤其对于传统企业而言，在战术设计落地的过程中，可能会存在一定挑战和困难，我建议你和你的公司如果有这方面的想法，就一定要谨慎评估自己的能力，选择最合适的方法落地 DDD。也不妨根据收获权衡一下，总体来说，DDD 可以给你带来以下收获：DDD 是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的标准设计过程，使得你的设计思路能够更加清晰，设计过程更加规范。DDD 善于处理与领域相关的拥有高复杂度业务的产品开发，通过它可以建立一个核心而稳定的领域模型，有利于领域知识的传递与传承。DDD 强调团队与领域专家的合作，能够帮助你的团队建立一个沟通良好的氛围，构建一致的架构体系。DDD 的设计思想、原则与模式有助于提高你的架构设计能力。无论是在新项目中设计微服务，还是将系统从单体架构演进到微服务，都可以遵循 DDD 的架构原则。DDD 不仅适用于微服务，也适用于传统的单体应用。

精彩评论：
面对复杂问题，解决办法通常是拆分，模块化，化整为零。领域驱动建模DDD是面向业务，对业务领域的划分和整合，是逻辑层面。微服务是面向物理落地，是对应用的物理形态进行拆分和整合。从软件工程过程角度看，DDD的战略设计输出物，领域模型及划分的区域，是微服务的输入，一个区域对应一个微服务，微服务运行框架、平台可以承载所有的微服务，提供微服务统一的运行框架，也就是承载所有的业务领域。可见领域驱动与微服务是在软件不同阶段使用的工具，技术或方法论，围绕一个共同的目标，搭建企业业务中台，企业级业务复用，快速的需求响应能力。DDD战略设计得输出，是微服务的输入。

翻了挺多留言，有一个感觉就是大家的容忍度特别低，总想把DDD的思想或者微服务架构一下子就在项目中完整的落地。就比如，只要使用DDD，在代码层面就不能使用MVC；只要使用微服务架构，就一定要基础设施完善，不然就是垃圾，这可能也是DDD一直推动不下去的原因之一。

人需要不断的学习，团队的认知也需要逐步的完善，是需要时间的。现在的代码是MVC的，没必要推翻，可以先在业务端多与市场、客户成功、产品等角色沟通，尝试用DDD的设计思想来建立合适的模型，等到团队都有这个sense的时候，再去慢慢搞定战术层面的东西。我认为，当业务领域模型足够健壮的时候，即使使用MVC模式，产品的健壮性和可维护性也会高很多。

只有让团队体会到领域设计的好处，才有可能继续推动DDD的落地。

另外一方面，微服务的基础设施也是逐步去构建完善，完全没有必要一开始就大而全。在业务初期，未必要建设庞大的监控系统，通过在代码中打印接口耗时、手动收集业务中的错误日志等方式来监控，也未尝不可，只要适合当前团队就好。

再者，也不用刻意去追求单元测试的覆盖率，能够保证重点业务接口的单元测试覆盖率即可。如果你真的有深入理解TDD的话，你就明白，TDD完全没有要求单元测试覆盖率这种指标，有些接口写单元测试真的只是浪费时间。

最后总结一下，饭是一口一口吃的，路也是一步一步走出来的，多给自己一点耐心，也多给团队一点时间。

我们公司现在也有这方面的想法，但是一直无从下手，主要原因是，
1、我们是给工厂做软件的，不同的工厂相同的功能需求会有有差异，这个怎么解决？显然一个工厂一个版本是不好的
2、不同工厂需要使用不同的数据库
3、功能模块主要有物料管理、订单管理、计划管理、出入库管理、库存管理等，里面功能模块较多
4、DDD怎么更好的去解决SAAS化的产品研发问题
作者回复: 第一个问题，我想知道不同工厂软件需求的差异主要在什么地方？如果差异在流程和服务编排，DDD的分层架构应用服务很合适。如果领域层业务逻辑差异不大的话，就比较好解决。个人感觉领域层的核心逻辑差异应该不会大。
第二个问题，DDD数据库方面采用依赖倒置的方式，实现业务逻辑的时候，不会有数据库方面的逻辑，都是领域对象的行为，数据库相关代码在仓储实现中实现。也就是说业务实现与数据库是松耦合的，换数据库的时候，只需要换仓储逻辑就可以了，不会影响核心业务逻辑。
第三方问题，你说的这几个子域相对清晰，直接在子域做事件风暴，建立领域模型，设计微服务就可以了。
第四个问题，见以上三条。总之，保持领域层领域模型的稳定，用应用层去适配外部需求的变化，用户接口层面向不同渠道提供个性数据服务。

当然是微服务架构，不是也得跟投资人宣称是

要说最大的问题，就是业务拎不清；让我更进一步分析这种状况，应该是就没有事实上的领域专家，只有很多充其量是熟悉现有业务流程的人，而这些人站在自己的视角阐述问题都没有问题，但是缺少能捏合起来统筹考虑的人，在我们的组织中（我怀疑大多数组织中都是这样），在产品研发团队，关于业务的话语权特别是信息垄断权是掌握在产品（经理）部门手中的，而微服务、DDD的武器却是掌握在技术部门手中，如果技术人员不赶紧学好吃透这些招式，这就对微服务的实际落地，DDD的推广应用，带来了巨大的障碍和困难，我觉得也别无他法，只能忍着被误解和做好顶雷背锅的心态，像Carty说的那样，技术团队中有人挺身而出去承担本该产品经理的责任吧，这样才能给DDD，微服务落地准备足够的营养…我还记得在这个团队在成立初期，产品总监戏称应该定一个组织结构设计架构师的岗位，我估计他主要是说给我这个技术架构师听的，而我只能一脸严肃地表达，确实组织架构应该根据你系统演化的需要来变更的，我就差说你回去好好看看书去不行吗？
作者回复: 其实你说的这种现象很普遍，很多企业都是业务的归业务，技术的归技术。不容易融合，这也是很多技术难以推行的原因。

我之前的公司从legacy单体应用转型为DDD微服务，
最大的问题是：

1. 使用消息队列的过程中，有很多事件不同步、死循环问题。
2. legacy数据库和新数据库的同步。
3. 做reporting的时候，不知道有什么好的招术。
   作者回复: 第一个问题，不清楚是设计的问题还是消息中间件组件选择的问题。
   第二个问题，数据库之间的同步可以采用两种方式，第一种定时扫描源端数据库获取增量数据，但是这种方式会增加数据库的负担和需要单独编写取数代码逻辑。第二种是采用数据库日志捕获技术CDC，但是不知道你这种数据库是否有CDC，如果没有，就不太方便了。
   第三个问题，不知道你的报表数据来源，如果是多个微服务，那建议你做一个数据平台，用于汇集各个微服务数据库的数据，所有的报表从这个数据平台获取。

微服务的关键不在服务的大小，在于边界是否清晰和有效隔离。单体应用向微服务架构演进的第一步是理清系统的领域架构，然后根据领域模型进行重构，每个领域都是“高内聚，低耦合”的模块，这样才能方便后期的拆分。至于服务拆分的大小，哪些需要拆，哪些不需要拆，哪些先拆，哪些后拆，还需要综合考量很多因素，比如团队的组织结构（小团队就不要拆分得太细了），性能，核心功能/非核心功能等等，业务拆分只是其中一小部分，数据拆分才是难点，总之先做好模块化（确定边界，做好隔离）才能实现想拆就拆。
作者回复: 是的，单体向微服务架构演进过程中的数据拆分是难点。如果边界清晰就相对容易很多。

我们是采用微服务模式进行系统的建设，我们现在是业务驱动开发，我们的每个服务都是独立的涉及业务的相关方面，存在重复性开发，这就是最大的问题。
在系统建设中出现工期紧的情况，没有多余的时间去划分业务域，抽象核心能力，分析之间的限界上下文怎么办？
我们是每个季度第一个月稍微轻松点，第二个月赶进度，第三个月上线如此往复，一个人负责多个系统，项目一般需求分析、系统设计、开发都是一个人，平时还要运维并开发新的功能需求，想要推行DDD，我们这种状况有什么好的建议吗？
作者回复: 推行DDD建议在整个企业内部考虑，至少是在一个完整的业务领域，如果在您的项目中早已经明确了应用功能范围，也就是确定了应用的业务领域边界，这样也就缺少了DDD战略设计。应用设计不是从业务领域边界划分开始，然后再进行微服务边界拆分和设计。
如果没有DDD战略设计，你们这种情况就只能从战术设计开始了，可以在应用中完成聚合和实体等设计，但是这种战术设计就没有业务整体的概念。
建议你们在企业内慢慢培养DDD文化，先从几个核心领域开始按照DDD方式进行应用设计，让领导看到价值后再慢慢推广到其它领域。

杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成，这句话老师是怎么理解的，我理解一个软件难道不是由各个组件构成的吗，基于架构的集成是什么概念
作者回复: 软件系统的架构通常需要包含以下四类核心要素：
1、元素（elements）：将系统拆分为一组元素 - 模块、组件、结构体、子系统；
2、关系（relationships）：不同元素之间的关系 - 交互、依赖 、继承、组合、聚合；
3、属性（properties）：每个元素具备的属性 - 名称、职责、接口、实现限制等；
4、原理（principles）：为什么这么设计 - 拆分依据、设计原则、决策原因等。
组件属于架构的一部分，一般来说，组件内的功能相对固定也比较稳定，我们在做企业集成的时候可能并不关心这个功能相对闭合的组件。而是通过类似分层（如BFF等）或者接口等架构定义来实现企业级多组件应用的集成，构建企业级应用。