10 | DDD、中台和微服务：它们是如何协作的？

Nov 4, 2019

10 | DDD、中台和微服务：它们是如何协作的？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

10 | DDD、中台和微服务：它们是如何协作的？

2019-11-04 欧创新来自北京

《DDD实战课》

课程介绍



讲述：欧创新

时长14:32大小9.97M



你好，我是欧创新。今天我一起来聊聊 DDD、中台和微服务的关系。
DDD 和微服务来源于西方，而中台诞生于中国的阿里巴巴。DDD 在二十多年前提出后一直默默前行，中台和微服务的理念近几年才出现，提出后就非常火爆。这三者看似风马牛不相及，实则缘分匪浅。中台是抽象出来的业务模型，微服务是业务模型的系统实现，DDD 作为方法论可以同时指导中台业务建模和微服务建设，三者相辅相成，完美结合。
你可能会问：凭什么 DDD 可以指导中台和微服务建设，究竟起到了什么作用呢？
DDD 有两把利器，那就是它的战略设计和战术设计方法。
中台在企业架构上更多偏向业务模型，形成中台的过程实际上也是业务领域不断细分的过程。在这个过程中我们会将同类通用的业务能力进行聚合和业务重构，再根据限界上下文和业务内聚的原则建立领域模型。而 DDD 的战略设计最擅长的就是领域建模。
那在中台完成领域建模后，我们就需要通过微服务来完成系统建设。此时，DDD 的战术设计又恰好可以与微服务的设计完美结合。可以说，中台和微服务正是 DDD 实战的最佳场景。
DDD 的本质我们先简单回顾一下 DDD 领域、子域、核心域、通用域和支撑域等概念，后面会用到。
在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，并在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。领域可分解为子域，子域可继续分为子子域，一直到你认为适合建立领域模型为止。
子域还会根据自身重要性和功能属性划分为三类子域，它们分别是核心域、支撑域和通用域。关于这三类子域更为详细的讲解，你可以回看[第 02 讲]。
接下来我们一起看下上面这张图，我选择了保险的几个重要领域，进行了高阶的领域划分。当然每个企业的领域定位和职责会有些不一样，那在核心域的划分上肯定会有一定差异。因此，当你去做领域划分的时候，请务必结合企业战略，这恰恰也体现了 DDD 领域建模的重要性。
通过领域划分和进一步的子域划分，我们就可以区分不同子域在企业内的功能属性和重要性，进而采取不同的资源投入和建设策略，这在企业 IT 系统的建设过程中十分重要，并且这样的划分还可以帮助企业进行中台设计。
中台的本质中台来源于阿里的中台战略（详见《企业 IT 架构转型之道：阿里巴巴中台战略思想与架构实战》钟华编著）。2015 年年底，阿里巴巴集团对外宣布全面启动中台战略，构建符合数字时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制，即作为前台的一线业务会更敏捷、更快速地适应瞬息万变的市场，而中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。
中台的本质其实就是提炼各个业务板块的共同需求，进行业务和系统抽象，形成通用的可复用的业务模型，打造成组件化产品，供前台部门使用。前台要做什么业务，需要什么资源，可以直接找中台，不需要每次都去改动自己的底层。
DDD、中台和微服务的协作模式我们在 [第 09 讲] 已经说过了传统企业和阿里中台战略的差异，那实际上更多的企业还是会聚焦在传统企业中台建设的模式，也就是将通用能力与核心能力全部中台化，以满足不同渠道核心业务能力的复用，那么接下来我们就还是把重点放在传统企业上。
传统企业可以将需要共享的公共能力进行领域建模，建设可共享的通用中台。除此之外，传统企业还会将核心能力进行领域建模，建设面向不同渠道的可复用的核心中台。
而这里的通用中台和核心中台都属于我们上一讲讲到的业务中台的范畴。
DDD 的子域分为核心域、通用域和支撑域。划分这几个子域的主要目的是为了确定战略资源的投入，一般来说战略投入的重点是核心域，因此后面我们就可以暂时不严格区分支撑域和通用域了。
领域、中台以及微服务虽然属于不同层面的东西，但我们还是可以将他们分解对照，整理出来它们之间的关系。你看下面这张图，我是从 DDD 领域建模和中台建设这两个不同的视角对同一个企业的业务架构进行分析。
如果将企业内整个业务域作为一个问题域的话，企业内的所有业务就是一个领域。在进行领域细分时，从 DDD 视角来看，子域可分为核心域、通用域和支撑域。从中台建设的视角来看，业务域细分后的业务中台，可分为核心中台和通用中台。
从领域功能属性和重要性对照来看，通用中台对应 DDD 的通用域和支撑域，核心中台对应 DDD 的核心域。从领域的功能范围来看，子域与中台是一致的。领域模型所在的限界上下文对应微服务。建立了这个映射关系，我们就可以用 DDD 来进行中台业务建模了。
我们这里还是以保险领域为例。保险域的业务中台分为两类：第一类是提供保险核心业务能力的核心中台（比如营销、承保和理赔等业务）；第二类是支撑核心业务流程完成保险全流程的通用中台（比如订单、支付、客户和用户等）。
这里我要提醒你一下：根据 DDD 首先要建立通用语言的原则，在将 DDD 的方法引入中台设计时，我们要先建立中台和 DDD 的通用语言。这里的子域与中台是一致的，那我们就可以将子域统一为中台。
中台通过事件风暴可以进一步细分，最终完成业务领域建模。中台业务领域的功能不同，限界上下文的数量和大小就会不一样，领域模型也会不一样。
当完成业务建模后，我们就可以采用 DDD 战术设计，设计出聚合、实体、领域事件、领域服务以及应用服务等领域对象，再利用分层架构模型完成微服务的设计。
以上就是 DDD、中台和微服务在应用过程中的协作模式。
中台如何建模？看完了三者的协作模式，我们就顺着上面的话题，接着来聊聊中台如何建模。
中台业务抽象的过程就是业务建模的过程，对应 DDD 的战略设计。系统抽象的过程就是微服务的建设过程，对应 DDD 的战术设计。下面我们就结合 DDD 领域建模的方法，讲一下中台业务建模的过程。
第一步：按照业务流程（通常适用于核心域）或者功能属性、集合（通常适用于通用域或支撑域），将业务域细分为多个中台，再根据功能属性或重要性归类到核心中台或通用中台。核心中台设计时要考虑核心竞争力，通用中台要站在企业高度考虑共享和复用能力。
第二步：选取中台，根据用例、业务场景或用户旅程完成事件风暴，找出实体、聚合和限界上下文。依次进行领域分解，建立领域模型。
由于不同中台独立建模，某些领域对象或功能可能会重复出现在其它领域模型中，也有可能本该是同一个聚合的领域对象或功能，却分散在其它的中台里，这样会导致领域模型不完整或者业务不内聚。这里先不要着急，这一步我们只需要初步确定主领域模型就可以了，在第三步中我们还会提炼并重组这些领域对象。
第三步：以主领域模型为基础，扫描其它中台领域模型，检查并确定是否存在重复或者需要重组的领域对象、功能，提炼并重构主领域模型，完成最终的领域模型设计。
第四步：选择其它主领域模型重复第三步，直到所有主领域模型完成比对和重构。
第五步：基于领域模型完成微服务设计，完成系统落地。
结合上面这张图，你可以大致了解到 DDD 中台设计的过程。DDD 战略设计包括上述的第一步到第四步，主要为：业务域分解为中台，对中台归类，完成领域建模，建立中台业务模型。DDD 战术设计是第五步，领域模型映射为微服务，完成中台建设。
那么如果还是以保险领域为例的话，完成领域建模后，里面的数据我们就可以填上了。这里我选取了通用中台的用户、客户和订单三个中台来做示例。客户中台提炼出了两个领域模型：客户信息和客户视图模型。用户中台提炼出了三个领域模型：用户管理、登录认证和权限模型。订单中台提炼出了订单模型。
这就是中台建模的全流程，当然看似简单的背后，若是遇上复杂的业务总会出现各种各样的问题，不然应用起来也不会有那么多的困难。如果你在按照以上流程实施的过程中遇到什么问题，欢迎在留言区和我讨论。
总结今天我们主要讨论了传统企业中台建设的一些思路，梳理了 DDD、中台和微服务的关系。DDD 的战略设计可用于中台业务建模，战术设计可指导中台微服务设计。相信 DDD 与中台的完美结合，可以让你的中台建设如虎添翼！
另外，这一讲只是开一个头，在下一讲中我还会以一个传统核心业务的中台建设案例，详细讲解中台的设计过程。
思考题你的企业是否在做中台？现在是用什么方法做中台业务建模呢？和 DDD 的设计方法相比，你觉得孰优孰劣？
欢迎留言分享，你也可以把今天所学分享给身边的朋友，邀请他一同交流、打卡。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 30

提建议

09 | 中台：数字转型后到底应该共享什么？

答疑：有关3个典型问题的讲解

 写留言

精选留言(37)

肖大保健
2019-11-16
我们做的跨境物流下单系统，涉及到用户，商品，支付，订单一些服务，用户，商品，支付相当于通用中台，订单这一块我有点矛盾，不知该归于核心还是通用，订单有，数据流的一些扭转，其他服务都是服务于订单，订单有核心的条件，但是从另外一方面讲，用户增删查改，这些操作订单，感觉也是比较通用型的，我该如何划分出核心中台
作者回复: 订单可能既是通用中台，又是核心中台，个人感觉订单在电商领域偏通用多一些，它就是一个很常见的公共能力中台。其实还是要看企业的战略，订单对电商企业太常见了，应该不会给企业带来太大的核心竞争力吧，除非这种订单模式是跟其它企业不太一样，而这种能力可以给公司带来非常大的优势。划分核心中台要看你的企业核心竞争力是否在这个领域？
共 6 条评论
23
钱晟龙🐲龍🐉
2020-02-22
用户管理+用户组织架构管理+认证&鉴权，我们都做到一个微服务里面了~~，这样看来可以拆3个出来 =。= 不过那样拆得太细的话，程序员写代码快速迭代期，项目来回切换发布，挺痛苦。前后分离一个repository 一个前端部署, 用户sso单点登录一个api层服务一个部署，服务层用一个服务把三种领域包圆了。老师怎么看这个问题，太细了会不会反而让系统变得维护时间变长。
展开
作者回复: 其实在不具备微服务的自动化运维条件的时候，不建议你拆的太细，你可以按照DDD的设计思想，做好微服务内部聚合之间的解耦，等运维条件具备后再拆分。其实这些聚合运行在同样一个微服务内部也是没有关系的，但是你要做好各种依赖的解耦，避免等你想拆的时候因为耦合度过高拆起来困难。
共 3 条评论
13
若水
2019-11-04
老师，我想咨询一下，画领域驱动设计图一般用什么样的工具
作者回复: 你说的设计图不知道是指哪类设计图。 DDD似乎还没有什么太好的用于设计的工具，有的话也就是UML之类的工具，很多工具用的也不是特顺手。DDD还缺少一些自动化的代码生成工具以及设计工具，这是它的短板。我作图一般用visio，费点劲，但是可以自由发挥。
共 4 条评论
7
张迪
2019-11-05
对照着图看，感觉中台和微服务没啥区别，感觉中台就是整合了通用微服务
作者回复: 中台是业务概念，很多同类功能的集合。微服务是这些功能的实现。差异还是挺大的。
共 3 条评论
6
阿玛铭
2019-11-05
欧老师好，我在搞一个DDD代码目录结构规范。大概做法：1. 列出DDD的术语表 2. 规定resources目录和包目录下的结构。3.拿一个子子域作为示例给出完整的目录结构。这件事工作量比较小，但我觉得比较有必要，不建立可执行的规范后面代码管理必然走向混乱。还有就是我担心有一些考虑不周到的地方，这块有可以提供的一些参考吗？
作者回复: 后面有一节专门讲代码目录。
共 4 条评论
5
发飙的蜗牛
2020-02-24
感觉讲的有点抽象，没有相关经验有些理解不了，DDD讲个人觉得要循序渐进，还没讲到如何使用DDD去落地微服务，就讲到中台微服务之间的关系这些了，跳跃有点大。
作者回复: 中台跟DDD的战略设计比较接近，所以从这个角度出发，就先讲了。后面实战的技术部分跟微服务设计有比较大的相关性。
共 2 条评论
3
Kian.Lee
2019-11-04
中台的业务模型和 DDD 的领域模型，我个人觉得只是两种设计思想对同一事物的不同描述，两者都是应对复杂软件系统的构建方法论。
作者回复: 是的。据说阿里中台业务建模时，有些采用的就是DDD的设计方法。
3
张子红
2021-08-16
中台架构本质是企业级服务，例如七牛图片存储，有多少企业需要企业级复用的服务，阿里业务线繁多，在良好设计的前提下，一定程度可以做到，但涉及多个部门的事情谁说了算呢，如果中小型企业，不建议搞中台化，事倍功半。
共 1 条评论
2
独孤九剑
2021-07-09
终于有了一个完整的微服务与中台架构设计方法论了，“子域”对标“中台”，“限界上下文”对标“微服务”，一针见血！！！感谢欧老师！
1
zygfengyuwuzu
2020-10-24
这一讲彻底搞明白了DDD，中台和微服务的关系了
作者回复: 很好！
1
如水
2020-08-29
一个领域的服务，还需要分前台与管理后台吗？
作者回复: 微服务的领域层的业务逻辑需要面向前端和基础资源进行解耦，将它们进行分层主要是为了适配和解耦。适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。主动适配主要是通过用户接口层。用户接口层的主要服务形态是Facade接口服务。Facade接口服务分为接口和实现两个部分，完成服务定向。通过assembler组装器，完成DO与DTO数据的转换和组装，完成前端应用与应用层数据的转换和交换。被动适配主要通过基础层的仓储来实现，领域逻辑面向接口编程，实现依赖倒置。仓储服务包括仓储接口和仓储实现两部分。仓储接口服务可以供应用层或者领域层服务或方法调用。仓储实现服务完成领域对象的持久化或提供数据初始化所需要的PO数据。
1
小谢同学
2020-02-02
请问老师在真实的ddd战略设计实践中，有没有和敏捷方法相结合的情况出现？我发现ddd中也会采用类似用户故事，用户旅程等工具
作者回复: 当然需要的，DDD的战略设计可以跟敏捷更好的结合，具体需要结合企业和团队情况灵活运用。
1
大导演
2020-01-10
老师您好，是否可以从多快好省四个角度，来解释中台或微服务呢，谢谢
作者回复: 中台偏业务多一些，主要考虑复用，微服务这是业务的系统落地，是实现方式，两者还是有差异的。
共 2 条评论
1
约书亚
2019-11-05
1.其实还是不太清楚如何区分核心域与通用域，支撑域。特别通用的就肯定不是核心域了是么？ 2.上篇里一直讲中台要“联通核心业务链路”，那映射到DDD，怎么才算是“联通核心域链路”呢？
作者回复: 中台是企业级的业务建模。DDD主要解决业务建模和微服务设计的问题。联通核心业务链路，需要在前台设计，让所有的业务环节打通。划分核心域的主要目的是为了战略投入。很多通用的可能也是核心域。
共 4 条评论
1
杨杰
2019-11-05
看图上把用户管理、登陆认证、权限管理分成了三个微服务，那是不是说这三个都要对应独立的数据库？
作者回复: 是的。里面实体会不一样。
1
朱振光
2019-11-05
是否中台就对应一个子域？只是看问题的角度不一样，有没有例外？
作者回复: 首先子域是个相对概念，子域可大可小。你需要将中台和子域的维度对齐，这样才会对应。当然会有例外的情况，我这里说的中台主要是业务中台。现在很多中台的概念，比如技术中台、AI中台等，有些地方可能就不好去做对应了。
1
JSLiuจุ๊บ¹⁸
2019-11-04
我的理解是中台是解决重复造轮的的方法，而DDD是建设中台的一种方法，比如前几期提到的，DDD领域的划分方法很适合解决中台建设中，中台能力的边界划分。现在有一个问题，DDD对需求分析有什么影响？包含那几方面。
作者回复: 对需求分析还是有些影响的。在事件风暴的过程中基本上就大概完成了需求分析的部分内容。在需求分析的文档部分也会有些差异，可能不再是那种长篇大论的需求文档了。一个微服务的需求文档可能是以聚合为单位的面向对象的方式。具体可以结合公司的情况，来慢慢适配。
共 2 条评论
1
FIGNT
2019-11-04
DDD的概念比较抽象，而中台比较具体。我的理解是中台是DDD的具体实践，和微服务直接挂钩。中台的概念和DDD一一对应。中台的概念是从DDD衍生出来的。
作者回复: 可以这么理解。
1
剑八
2022-07-20
中台核心目标是高效复用及适度支持扩展，不仅是架构形态也涉及组织架构，通常会有解决方案及中台团队。解决方案贴合业务做定制，中台沉淀可复用资产。微服务核心目标是解耦，实现业务职责内聚的业务服务。微服务看的是整体的业务架构如何物理上剥离。中台可以用微服务来实现，可以由微服务组合，如交易中台本身是电商域中的一个微服务。
展开
剑八
2022-07-17
ddd战略设计是划分域，那这个依据是什么？如果一个新业务，通常是不了解，也没有业界经验可借鉴，此时是不是先战术设计，找实体，形成聚合，限界上下文，最终得到子域

