01 领域驱动设计：微服务设计为什么要选择DDD？
你好，我是欧创新。
我们知道，微服务设计过程中往往会面临边界如何划定的问题，我经常看到项目团队为微服务到底应该拆多小而争得面红耳赤。不同的人会根据自己对微服务的理解而拆分出不同的微服务，于是大家各执一词，谁也说服不了谁，都觉得自己很有道理。
那在实际落地过程中，我也确实见过不少项目在面临这种微服务设计困惑时，是靠拍脑袋硬完成的，上线后运维的压力就可想而知了。那是否有合适的理论或设计方法来指导微服务设计呢？当你看到这一讲的题目时，我想你已经知道答案了。
没错，就是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不仅适用于微服务，也适用于传统的单体应用。
思考题
你的公司是否在实施微服务架构，你在微服务设计过程中面临的最大问题是什么？
欢迎留言和我分享你的思考和疑惑，你也可以把今天所学分享给身边的朋友，邀请他加入探讨，共同进步。
- Geek_a91670 👍（13） 💬（8）
事件风暴到底是什么啊?
2019-10-21 - 吴建中 👍（204） 💬（13）
面对复杂问题，解决办法通常是拆分，模块化，化整为零。领域驱动建模DDD是面向业务，对业务领域的划分和整合，是逻辑层面。微服务是面向物理落地，是对应用的物理形态进行拆分和整合。从软件工程过程角度看，DDD的战略设计输出物，领域模型及划分的区域，是微服务的输入，一个区域对应一个微服务，微服务运行框架、平台可以承载所有的微服务，提供微服务统一的运行框架，也就是承载所有的业务领域。可见领域驱动与微服务是在软件不同阶段使用的工具，技术或方法论，围绕一个共同的目标，搭建企业业务中台，企业级业务复用，快速的需求响应能力。DDD战略设计得输出，是微服务的输入。
2019-12-14 - Skye 👍（132） 💬（13）
翻了挺多留言，有一个感觉就是大家的容忍度特别低，总想把DDD的思想或者微服务架构一下子就在项目中完整的落地。就比如，只要使用DDD，在代码层面就不能使用MVC；只要使用微服务架构，就一定要基础设施完善，不然就是垃圾，这可能也是DDD一直推动不下去的原因之一。 人需要不断的学习，团队的认知也需要逐步的完善，是需要时间的。现在的代码是MVC的，没必要推翻，可以先在业务端多与市场、客户成功、产品等角色沟通，尝试用DDD的设计思想来建立合适的模型，等到团队都有这个sense的时候，再去慢慢搞定战术层面的东西。我认为，当业务领域模型足够健壮的时候，即使使用MVC模式，产品的健壮性和可维护性也会高很多。 只有让团队体会到领域设计的好处，才有可能继续推动DDD的落地。 另外一方面，微服务的基础设施也是逐步去构建完善，完全没有必要一开始就大而全。在业务初期，未必要建设庞大的监控系统，通过在代码中打印接口耗时、手动收集业务中的错误日志等方式来监控，也未尝不可，只要适合当前团队就好。 再者，也不用刻意去追求单元测试的覆盖率，能够保证重点业务接口的单元测试覆盖率即可。如果你真的有深入理解TDD的话，你就明白，TDD完全没有要求单元测试覆盖率这种指标，有些接口写单元测试真的只是浪费时间。 最后总结一下，饭是一口一口吃的，路也是一步一步走出来的，多给自己一点耐心，也多给团队一点时间。
2021-01-20 - Geek_9695b4 👍（51） 💬（7）
我们公司现在也有这方面的想法，但是一直无从下手，主要原因是， 1、我们是给工厂做软件的，不同的工厂相同的功能需求会有有差异，这个怎么解决？显然一个工厂一个版本是不好的 2、不同工厂需要使用不同的数据库 3、功能模块主要有物料管理、订单管理、计划管理、出入库管理、库存管理等，里面功能模块较多 4、DDD怎么更好的去解决SAAS化的产品研发问题
2019-10-25 - 女干部 👍（34） 💬（8）
我能说我等极客时间出这个等了1年吗？
2019-10-14 - 雷霹雳的爸爸 👍（30） 💬（4）
当然是微服务架构，不是也得跟投资人宣称是 要说最大的问题，就是业务拎不清；让我更进一步分析这种状况，应该是就没有事实上的领域专家，只有很多充其量是熟悉现有业务流程的人，而这些人站在自己的视角阐述问题都没有问题，但是缺少能捏合起来统筹考虑的人，在我们的组织中（我怀疑大多数组织中都是这样），在产品研发团队，关于业务的话语权特别是信息垄断权是掌握在产品（经理）部门手中的，而微服务、DDD的武器却是掌握在技术部门手中，如果技术人员不赶紧学好吃透这些招式，这就对微服务的实际落地，DDD的推广应用，带来了巨大的障碍和困难，我觉得也别无他法，只能忍着被误解和做好顶雷背锅的心态，像Carty说的那样，技术团队中有人挺身而出去承担本该产品经理的责任吧，这样才能给DDD，微服务落地准备足够的营养...我还记得在这个团队在成立初期，产品总监戏称应该定一个组织结构设计架构师的岗位，我估计他主要是说给我这个技术架构师听的，而我只能一脸严肃地表达，确实组织架构应该根据你系统演化的需要来变更的，我就差说你回去好好看看书去不行吗？
2019-10-30 - 忠厚 👍（20） 💬（3）
中台是战略目标，DDD是设计思想，微服务是落地手段，云原生是落地基础....企业数字化转型四大核心知识体系，一个都不能少，哈哈哈哈...
2020-03-22 - huaweichen 👍（18） 💬（3）
我之前的公司从legacy单体应用转型为DDD微服务， 最大的问题是： 1. 使用消息队列的过程中，有很多事件不同步、死循环问题。 2. legacy数据库和新数据库的同步。 3. 做reporting的时候，不知道有什么好的招术。
2019-11-04 - 姚俊 👍（14） 💬（2）
从2016年偶然间发现了springcloud springboot，于是开始带领团队玩起了微服务，在有一些技术积累之后，开始反过来看做过的项目，发现微服务的拆分并没有带来多少好好处，于是今年开始ddd试错。在拆分过程中，个人碰到的几大问题就是 1、数据库彻底拆分之后，带来的编码问题，和多服务调用的性能问题，举个例子，性别代码表，在n多个系统都需要的情况下，如果复制，也数据库没有彻底拆分，或者有冗余，彻底拆分的话，原来关联查询简单的sql，则变成服务之间的调用，可能存在性能问题。比较棘手 2、接触ddd有几个月吧，也在按照这个模式，重新构建项目，只是实体，聚合根在复杂的业务逻辑下，如何拆分和聚合，一直觉得没掌握到位。希望后续案例可以给我启发
2019-10-15 - 方堃 👍（14） 💬（1）
我觉得微服务现在转型有个挺大的问题就是团队认识深度。因为现在好多项目都是先简单的以单机项目为基础开发，追求上线速度。后续发现项目越来越大才考虑进行架构方向的整理。导致很有可能出现早期只有开发产品没有架构师参与。这时候转型，架构师多久能吃透现有的业务就是转型速度的瓶颈了。毕竟产品不了解代码，开发人员又往往只盯着自己的模块缺少整体的了解
2019-10-14 - 肖大保健 👍（13） 💬（1）
目前公司用的是spring boot 框架，根据业务也做了明显得服务拆分（接单web，调度服务，订单服务，用户服务，资金服务，api服务 等），后期打算把数据层（mysql，mongo，redis）单独拆分出去，web层controller再单独拆分做HA 或者 ng，不知道算不算的上微服务架构，我们在做服务拆分，功能聚合这块是按业务模块来的 问题一：服务的功能界限该如何划定（按功能，还是按业务，有点矛盾） 问题二：服务调用，横向一个个调用，还是按web或者调度中转，比较好？（也存在争议） 问题三：文章中提到界定上下文，请问在服务中该如何体现，不是很明白
2019-10-16 - Jxin 👍（10） 💬（2）
1.一年前学的ddd，半年前学的重构，现如今项目从架构到核心业务都重构了。这个专栏，实在等了太久。 2.目前公司采用了微服务组件和框架。但绝对不是微服务，缺少合理的业务拆分，缺少对应的敏捷开发基建（没有cicd，没有测试用例，没有自动化回归测试，没有完善的监控平台，微服务技术的引入很可能弊大于利）。我将这架构认定为传统soa引入微服务组件和框架，依旧是传统soa。拆得再细都还是单体，因为每个服务不能自成体系，相互依赖严重。 3.难点很多。业务债高难还，员工（所有业务开发）在业务的架构抽象上认知太浅，基础架构平台从0搭建，效能工具平台从0搭建，最难的是，2b项目改造价值有限，如果没有升级为saas平台并带来额外利益的可能，那么一切改造都是空话，能用就行。
2019-10-16 - Dr 👍（10） 💬（4）
实战源代码，成体系吗？还是散落在文章里面？有的话，哪里可以下载？理论看了很多，缺一套代码，琢磨琢磨。
2019-10-14 - TH 👍（8） 💬（5）
DDD是针对业务的，那么到底怎么理解“业务”呢？什么属于业务，什么不属于业务呢？尤其是业务与技术、基础设施、中间件之间的关系怎么划分？ 换句话说，DDD是否适合技术框架、技术平台甚至技术中台的建设呢？比如我要开发一个代码部署系统或者配置管理系统，这样的系统是否适用DDD呢？因为对整个公司来说它们应该属于基础设施层的东西吧。 DDD是否存在大系统套小系统的形式？比如整个公司业务用DDD来设计，然后业务中的某个子系统也用DDD来设计，它们可以嵌套吗？
2019-10-15 - james.d 👍（7） 💬（1）
微服务的关键不在服务的大小，在于边界是否清晰和有效隔离。单体应用向微服务架构演进的第一步是理清系统的领域架构，然后根据领域模型进行重构，每个领域都是“高内聚，低耦合”的模块，这样才能方便后期的拆分。至于服务拆分的大小，哪些需要拆，哪些不需要拆，哪些先拆，哪些后拆，还需要综合考量很多因素，比如团队的组织结构（小团队就不要拆分得太细了），性能，核心功能/非核心功能等等，业务拆分只是其中一小部分，数据拆分才是难点，总之先做好模块化（确定边界，做好隔离）才能实现想拆就拆。
2019-12-19