极客时间已完结课程限时免费阅读

11 | DDD实践：如何用DDD重构中台业务模型？

11 | DDD实践：如何用DDD重构中台业务模型？-极客时间

11 | DDD实践：如何用DDD重构中台业务模型？

2019-11-08 欧创新 来自北京
《DDD实战课》
课程介绍

讲述：欧创新

时长19:26大小13.32M

你好，我是欧创新。
进入两千年后，随着互联网应用的快速发展，很多传统企业开始触网，建设自己的互联网电商平台。后来又随着微信和 App 等移动互联应用的兴起，又形成了新一轮的移动应用热潮。这些移动互联应用大多面向个人或者第三方，市场和需求变化快，需要以更敏捷的速度适应市场变化，为了保持快速响应能力和频繁发版的要求，很多时候这些移动互联网应用是独立于传统核心系统建设的，但两者承载的业务大部分又都是同质的，因此很容易出现业务能力重叠的问题。
阿里巴巴过去带动了传统企业向互联网电商转型。而如今又到了一个新的历史时期，在阿里巴巴提出中台战略后，很多企业又紧跟它的步伐，高举中台大旗，轰轰烈烈地开始了数字化转型之路。
那么传统企业在中台转型时，该如何从错综复杂的业务中构建中台业务模型呢？今天我就用一个传统企业中台建模的案例，带你一起用 DDD 的设计思想来构建中台业务模型。

传统企业应用分析

互联网电商平台和传统核心应用，两者面向的渠道和客户不一样，但销售的产品却很相似，它们之间的业务模型既有相同的地方，又有不同的地方。
现在我拿保险行业的互联网电商和传统核心应用来做个对比分析。我们看一下下面这张图，这两者在业务功能上会有很多相似和差异，这种相似和差异主要体现在四个方面。
1. 核心能力的重复建设。由于销售同质保险产品，二者在核心业务流程和功能上必然相似，因此在核心业务能力上存在功能重叠是不可避免的。传统保险核心应用有报价、投保、核保和出单功能，同样在互联网电商平台也有。这就是核心能力的重复建设。
2. 通用能力的重复建设。传统核心应用的通用平台大而全，通常会比较重。而互联网电商平台离不开这些通用能力的支撑，但为了保持敏捷性，一般会自己建设缩小版的通用功能，比如用户、客户等。这是通用能力的重复建设。
3. 业务职能的分离建设。有一类业务功能，在互联网电商平台中建设了一部分，在传统核心应用中也建设了一部分，二者功能不重叠而且还互补，组合在一起是一个完整的业务职能。比如缴费功能，互联网电商平台主要面向个人客户，于是采用了支付宝和微信支付的方式。而传统核心应用主要是柜台操作，仍在采用移动 POS 机的缴费方式。二者都是缴费，为了保证业务模型的完整性，在构建中台业务模型时，我们可以考虑将这两部分模型重组为一个完整的业务模型。
4. 互联网电商平台和传统核心功能前后完全独立建设。传统核心应用主要面向柜台，不需要互联网电商平台的在线客服、话务、订单和购物车等功能。而互联网电商平台主要面向个人客户，它不需要后端比较重的再保、佣金、打印等功能。在构建中台业务模型时，对这种情况应区别对待，将面向后端业务管理的应用沉淀到后台，将前端能力构建为面向互联网渠道的通用中台，比如订单等。

如何避免重复造轮子？

要避免重复建设，就要理解中台的理念和思想。前面说了“中台是企业级能力复用平台”，“复用”用白话说就是重复使用，就是要避免重复造轮子的事情。
中台的设计思想与“高内聚、低耦合”的设计原则是高度一致的。高内聚是把相关的业务行为聚集在一起，把不相关的行为放在其它地方，如果你要修改某个业务行为，只需要修改一处。对了！中台就是要这样做，按照“高内聚、松耦合”的原则，实现企业级的能力复用！
那如果你的企业遇到了重复造轮子的情况，应该怎么处理？
你需要站在企业高度，将重复的需要共享的通用能力、核心能力沉淀到中台，将分离的业务能力重组为完整的业务板块，构建可复用的中台业务模型。前端个性能力归前端，后端管理能力归后台。建立前、中、后台边界清晰，融合协作的企业级可复用的业务模型。

如何构建中台业务模型？

我们可以用 DDD 领域建模的方法来构建中台业务模型。你可以选择两种建模策略：自顶向下和自底向上的策略。具体采用哪种策略，你需要结合公司的具体情况来分析，下面我就来介绍一下这两种策略。
1. 自顶向下的策略
第一种策略是自顶向下。这种策略是先做顶层设计，从最高领域逐级分解为中台，分别建立领域模型，根据业务属性分为通用中台或核心中台。领域建模过程主要基于业务现状，暂时不考虑系统现状。自顶向下的策略适用于全新的应用系统建设，或旧系统推倒重建的情况。
由于这种策略不必受限于现有系统，你可以用 DDD 领域逐级分解的领域建模方法。从下面这张图我们可以看出它的主要步骤：第一步是将领域分解为子域，子域可以分为核心域、通用域和支撑域；第二步是对子域建模，划分领域边界，建立领域模型和限界上下文；第三步则是根据限界上下文进行微服务设计。
2. 自底向上的策略
第二种策略是自底向上。这种策略是基于业务和系统现状完成领域建模。首先分别完成系统所在业务域的领域建模；然后对齐业务域，找出具有同类或相似业务功能的领域模型，对比分析领域模型的差异，重组领域对象，重构领域模型。这个过程会沉淀公共和复用的业务能力，会将分散的业务模型整合。自底向上策略适用于遗留系统业务模型的演进式重构。
下面我以互联网电商和传统核心应用的几个典型业务域为例，带你了解具体如何采用自底向上的策略来构建中台业务模型，主要分为这样三个步骤。
第一步：锁定系统所在业务域，构建领域模型。
锁定系统所在的业务域，采用事件风暴，找出领域对象，构建聚合，划分限界上下文，建立领域模型。看一下下面这张图，我们选取了传统核心应用的用户、客户、传统收付和承保四个业务域以及互联网电商业务域，共计五个业务域来完成领域建模。
从上面这张图中，我们可以看到传统核心共构建了八个领域模型。其中用户域构建了用户认证和权限两个领域模型，客户域构建了个人和团体两个领域模型，传统收付构建了 POS 刷卡领域模型，承保域构建了定报价、投保和保单管理三个领域模型。
互联网电商构建了报价、投保、订单、客户、用户认证和移动收付六个领域模型。
在这些领域模型的清单里，我们可以看到二者之间有很多名称相似的领域模型。深入分析后你会发现，这些名称相似的领域模型存在业务能力重复，或者业务职能分散（比如移动支付和传统支付）的问题。那在构建中台业务模型时，你就需要重点关注它们，将这些不同领域模型中重复的业务能力沉淀到中台业务模型中，将分散的领域模型整合到统一的中台业务模型中，对外提供统一的共享的中台服务。
第二步：对齐业务域，构建中台业务模型。
在下面这张图里，你可以看到右侧的传统核心领域模型明显多于左侧的互联网电商，那我们是不是就可以得出一个初步的结论：传统核心面向企业内大部分应用，大而全，领域模型相对完备，而互联网电商面向单一渠道，领域模型相对单一。
这个结论也给我们指明了一个方向：首先我们可以将传统核心的领域模型作为主领域模型，将互联网电商领域模型作为辅助模型来构建中台业务模型。然后再将互联网电商中重复的能力沉淀到传统核心的领域模型中，只保留自己的个性能力，比如订单。中台业务建模时，既要关注领域模型的完备性，也要关注不同渠道敏捷响应市场的要求。
有了上述这样一个思路，我们就可以开始构建中台业务模型了。
我们从互联网电商和传统核心的领域模型中，归纳并分离出能覆盖两个域的所有业务子域。通过分析，我们找到了用户、客户、承保、收付和订单五个业务域，它们是可以用于领域模型对比分析的基准域。
下面我以客户为例，来给你讲一下客户中台业务模型的构建过程。
互联网电商客户主要面向个人客户，除了有个人客户信息管理功能外，基于营销目的它还有客户积分功能，因此它的领域模型有个人和积分两个聚合。
而传统核心客户除了支持个人客户外，还有单位和组织机构等团体客户，它有个人和团体两个领域模型。其中个人领域模型中除了个人客户信息管理功能外，还有个人客户的评级、重复客户的归并和客户的统一视图等功能，因此它的领域模型有个人、视图、评级和归并四个聚合。
构建多业务域的中台业务模型的过程，就是找出同一业务域内所有同类业务的领域模型，对比分析域内领域模型和聚合的差异和共同点，打破原有的模型，完成新的中台业务模型重组或归并的过程。
我们将互联网电商和传统核心的领域模型分解后，我们找到了五个与个人客户领域相关的聚合，包括：个人、积分、评级、归并和视图。这五个聚合原来分别分散在互联网电商和传统核心的领域模型中，我们需要打破原有的领域模型，进行功能沉淀和聚合的重组，重新找出这些聚合的限界上下文，重构领域模型。
最终个人客户的领域模型重构为：个人、归并和视图三个聚合重构为个人领域模型（客户信息管理），评级和积分两个聚合重构为评级积分领域模型（面向个人客户）。到这里我们就完成了个人客户领域模型的构建了。
好像还漏掉点什么东西呢？对了，还有团队客户领域模型！其实团体客户很简单。由于它只在传统核心中出现，我们将它在传统核心中的领域模型直接拿过来用就行了。
至此我们就完成了客户中台业务模型的构建了，客户中台构建了个人、团体和评级积分三个领域模型。
通过客户中台业务模型的构建，你是否 get 到构建中台业务模型的要点了呢？总结成一句话就是：“分域建模型，找准基准域，划定上下文，聚合重归类。”
其它业务域其实也是一样的过程，在这里我就不一一讲述了，你可以自己练习一下，作为课后作业。完成后你可以对照下面这张图看一下，这就是其它业务域重构后的中台业务模型。
第三步：中台归类，根据领域模型设计微服务。
完成中台业务建模后，我们就有了下面这张图。从这张图中我们可以看到总共构建了多少个中台，中台下面有哪些领域模型，哪些中台是通用中台，哪些中台是核心中台，中台的基本信息等等，都一目了然。你根据中台下的领域模型就可以设计微服务了。

重构过程中的领域对象

上面主要是从聚合的角度来描述中台业务模型的重组，是相对高阶的业务模块的重构。业务模型重构和聚合重组，往往会带来领域对象和业务行为的变化。下面我带你了解一下，在领域模型重组过程中，发生在更底层的领域对象的活动。
我们还是以客户为例来讲述。由于对象过多，我只选取了部分领域对象和业务行为。
传统核心客户领域模型重构之前，包含个人、团体和评级三个聚合，每个聚合内部都有自己的聚合根、实体、方法和领域服务等。
互联网电商客户领域模型重构前包含个人和积分两个聚合，每个聚合包含了自己的领域对象、方法和领域服务等。
传统核心和互联网电商客户领域模型重构成客户中台后，建立了个人、团体和评级积分三个领域模型。其中个人领域模型有个人聚合，团体领域模型有团体聚合，评级积分领域模型有评级和积分两个聚合。这些领域模型的领域对象来自原来的领域模型，但积分评级是重组后的领域模型，它们原来的聚合会带着各自的领域对象，加入到新的领域模型中。
这里还要注意：部分领域对象可能会根据新的业务要求，从原来的聚合中分离，重组到其它聚合。新领域模型的领域对象，比如实体、领域服务等，在重组后可能还会根据新的业务场景和需求进行代码重构。

总结

今天我们一起讨论了传统企业中台数字化转型，在面对多个不同渠道应用重复建设时，如何用 DDD 领域建模的思想来构建中台业务模型。中台业务建模有自顶向下和自底向上两种策略，这两种策略有自己的适用场景，你需要结合自己公司的情况选择合适的策略。
其实呢，中台业务模型的重构过程，也是微服务架构演进的过程。业务边界即微服务边界，业务边界做好了，微服务的边界自然就会很好。

思考题

思考一下你公司的应用系统建设现状，是否存在重复建设的问题？你能否借用今天学到的方法来尝试构建中台呢？
欢迎留言分享，你也可以把今天所学分享给身边的朋友，邀请他一同交流、打卡。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 28

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
答疑：有关3个典型问题的讲解
下一篇
12 | 领域建模：如何用事件风暴构建领域模型？
 写留言

精选留言(50)

  • 深山小书童
    2019-11-08
    接触ddd的概念也蛮多年了，确实如老师所说，微服务的兴起让大家有自然的想起了ddd。但是要将ddd落地，不知道在代码层面如何去分层是最让人困扰的。以java web开发为例，controller，dao，service怎么和应用服务，领域服务，聚合等对应起来呢？老师能不能展示一下框架里面怎么去组织这些概念，这样作为研发人员会比较好理解。ddd的经典三本书里面就是缺少这种东西，互联网小厂由于能力有限很难将其理解和落地。一直期待一门课从代码层面开始自底向上来讲解ddd，反而会更好理解。一直反复讲ddd的好处，感觉浮在表面。
    展开

    作者回复: 其实DDD的核心思想是在于划分领域边界从而来解耦。我认为领域模型才是DDD在微服务设计的关键，只有构建了边界清晰的领域模型的边界，才有可能设计出高质量的微服务。在建立领域模型后，微服务内部可以用DDD战术设计方法，传统的开发方法也不是不可以，有时候在性能方面表现更优秀。 后面我有一节专门讲解这些对象之间是如何协作的，另外也有一讲来介绍DDD的代码目录结构和模型。

    共 10 条评论
    44
  • 墨名次
    2019-11-09
    DDD是中台、微服务的产品经理

    作者回复: 比喻很形象！

    共 3 条评论
    26
  • 小毅
    2019-11-08
    建议老师，多讲讲怎么做的领域、聚合根、实体的划分，讲讲实施层面怎么做的？而不是直接抛出你最终的结果，我觉得这才是要学DDD的精髓。看到现在知道了很多名词，但是依然并不知道DDD具体如何实施，具体场景下拿什么依据作为划分和聚类的参考~ 建议对于文章中的例子，比如您举的保险类例子，可以多补充些业务背景，这样才能在战术层面搞明白实施和落地的流程，而不是悬浮在半空中~
    展开

    作者回复: 这一节信息量比较大，后面小的案例里有介绍。

    21
  • 蜗牛慢慢爬
    2019-11-11
    看了11个课程了，最大的疑问就是怎么划分？ 老师每次都拿出你已经划分好的领域，感觉很空泛，领会不到精髓

    作者回复: 这一节的内容有点多，没有做过细的分析，你可以看下一节哈。第12节有详细的领域建模分析过程。

    12
  • Scott
    2019-11-09
    很多人提到代码，其实代码方面我觉得可以看看 Domain modeling made functional 这书。
    共 2 条评论
    9
  • 祥敏
    2019-11-08
    看来要公布Github的仓库了，要不怎么是实践篇@@@

    作者回复: DDD用于微服务设计的关键就是先建立领域模型，有了边界清晰的领域模型，才能设计出高质量的微服务。在微服务设计时不能脱离领域模型来谈微服务。它们两者之间是必不可少的前后贯通的关系，可能开发人员只关心用DDD来做微服务的开发，并不关心领域建模。领域建模就是DDD的战略实战。而且这种战略设计和分析过程比战术设计更重要。

    共 2 条评论
    4
  • 日月星辰
    2020-05-29
    感觉这里说的中台就是各个微服务嘛，之前一直觉得中台是一些通用业务的集合，是不会跟数据库直接交互的。那现在这样理解就是说中台也可以跟数据库直接交互了吗？

    作者回复: 中台是偏业务架构的，一个中台可能会有多个限界上下文，一个限界上下文可以构建一个领域模型，一个领域模型可以设计为一个微服务。当然在进行中台领域模型设计的时候，会考虑通用业务能力的复用。中台会完成业务建模，然后才是微服务按照中台的领域模型完成落地，它们是两个不同阶段的东西，最终与数据库交互的是微服务。

    共 5 条评论
    3
  • 信了
    2020-03-20
    前端个性能力归前端，后端管理能力归后台。建立前、中、后台边界清晰，融合协作的企业级可复用的业务模型。文中所说前端个性能力具体是什么？后端管理能力又是什么？前、中、后台边界清晰，这三个的边界怎么定义的？越来越模糊了，求解答？？

    作者回复: 首先采用微服务后，前后端就分离了，前端面向应用，后端主要是领域模型和业务逻辑。 前端主要是面向用户的一些页面操作或者业务流程，不同渠道的用户可能会需求和操作要求不一样，这一部分的变化就由前台应用来控制。后端主要实现业务逻辑和业务管控要求，只有涉及到业务逻辑变化的时候，才会调整中台和后台的业务逻辑。前台需求的变化，在前台调整完成，业务逻辑相关的需求变化在中台和后台完成，他们之间还有应用层的应用服务的编排，进一步隔离前台需求对中台和后台业务逻辑的影响。

    共 2 条评论
    3
  • 达文西
    2019-12-19
    代码可以参考这个 https://github.com/JoeCao/qbike
    共 2 条评论
    3
  • Steven
    2021-12-31
    请问老师，传统客户领域的个人聚合中的InquiryPersonInfo 命令，在重组后不见了，是不需要了还是放到别的地方了？
    1
  • Jerry
    2021-03-03
    请教如何划分子域（限界上下文），如果是利用事件风暴然后对聚合进行划分，那么什么样的聚合应该划分在同一个限界上下文呢?
    1
  • 瓜瓜
    2019-11-24
    聚合内的实体都是通过聚合根来进行访问的，这个有没有相关的例子，感谢老师

    作者回复: 聚合根内会定义引用的实体，在聚合根内部直接使用引用的实体属性或者方法就可以了。 这些实体的方法会被封装成领域服务或者应用服务。外界不需要关心这些实体内的属性或者方法实现了。

    1
  • abc-web
    2019-11-13
    欧老师好，我说下我对ddd在中台建设中所起作用的看法，不当之处请指点；ddd为中台所涉及到的领域模型梳理提供了方法指引，并对微服务的划分提供了参考标准；但有了这些对一个业务中台的建设还不是完备的；因为中台提供了业务能力服用层，也就是说抽象出了可服用的公共能力，但每个使用该能力的场景是不一样的，这样在该能力上的定制需求的满足是就出现了，这就需要中台有扩展能力，来适应这些需求；所以中台建设不单是微服务的合理拆分，可扩展能力的架构设计也是中台建设的关键；
    展开

    作者回复: 是这样的。

    1
  • 若水
    2019-11-10
    老师好，我有两个疑问。①、按以上流程分析微服务的划分感觉粒度很小。一个微服务就是一个工程，项目粒度如何决定？②客户也是用户的一种，为什么客户和用户在两个微服务？

    作者回复: 理论上一个限界上下文对应一个微服务。具体拆多细根据企业的微服务的运维能力，如果有云平台，自动化发布和运维工具以及监控等工具，可以按照限界上下文大小来拆分。如果不具备这些能力，建议还是粗一点比较好。 你说的客户应该是面向个人的客户吧。传统有两类用户，一种是内部用户，另外一部分是个人客户，其中一部分个人客户也是用户。个人客户和用户会有一部分重叠，设计的时候按照客户和用户两个不同的集合来设计，但是部分个人用户来源于个人客户，用户可以引用个人客户的数据。

    共 2 条评论
    1
  • 李亮亮
    2022-12-17 来自上海
    互联网电商中会含有一些特有的领域模型，这些特有的模型在传统核心领域模型中并不存在。老师讲的这句“中台业务建模时，既要关注领域模型的完备性，也要关注不同渠道敏捷响应市场的要求”怎么理解呢，这种互联网特有的领域模型要放在中台里，还是由互联网电商这种前台系统关注呢
  • 加多
    2022-10-03 来自北京
    老师你好，请问战略设计和战术设计的产物是什么？比如战略设计的产物是一张限界上下文图（包含领域细分和领域边界的图）？战术设计产物是包含比如领域对象、值对象、聚合跟、领域服务的类图？
  • Jacqueline 牛晓莉
    2022-05-03
    我本人是业务出身， 读欧老师的课， 有醍醐灌顶之效果。
  • 无名
    2022-03-15
    老师能不能着重讲下防腐层的设计，在系统建设过程中，我们经常要对接很多的外部系统，以信用保险为例，上游我们需要对接不同的资产平台，下游我们要对接不同的资金方(银行)，特别每个银行的信贷流程自己对账方式很难以标准化。我们的系统怎么分别对上游系统和下游系统进行防腐(代码层面防腐层应该做在分层架构的哪一层)
  • 危观添 Tim.Ngai
    2021-12-23
    如何看待用户与客户之间的领域划分？是否可以合并，还是说客户是属于业务领域的对象、实体，所以形成单独的业务域？
  • Monday
    2021-12-21
    老师咨询一下我们现在项目上的疑问 比如电商库存中心设计三级库存业务逻辑中实体仓向逻辑仓自动分货、手动分货，逻辑仓向触点仓自动分货手动分货，三级库存更新设计业务（补货入库、调拨入/出库）是运营管理人员直接操作中台？还是业务中台将能力以接口的形式对外暴露？