关于后端:DDD重构中台业务

大家好，我是易安！明天咱们谈一谈如何应用 DDD 重构中台业务。

DDD 有两把利器，那就是它的策略设计和战术设计办法。中台在企业架构上更多偏差业务模型，造成中台的过程实际上也是业务畛域一直细分的过程。在这个过程中咱们会将同类通用的业务能力进行聚合和业务重构，再依据限界上下文和业务内聚的准则建设畛域模型。而 DDD 的策略设计最善于的就是领域建模。

那在中台实现领域建模后，咱们就须要通过微服务来实现零碎建设。此时，DDD 的战术设计又恰好能够与微服务的设计完满联合。能够说，中台和微服务正是 DDD 实战的最佳场景。

DDD 的实质

在钻研和解决业务问题时，DDD 会依照肯定的规定将业务畛域进行细分，畛域细分到肯定的水平后，DDD 会将问题范畴限定在特定的边界内，并在这个边界内建设畛域模型，进而用代码实现该畛域模型，解决相应的业务问题。畛域可分解为子域，子域可持续分为子子域，始终到你认为适宜建设畛域模型为止。

子域还会依据本身重要性和功能属性划分为三类子域，它们别离是外围域、撑持域和通用域。

接下来咱们一起看下下面这张图，我抉择了保险的几个重要畛域，进行了高阶的畛域划分。当然每个企业的畛域定位和职责会有些不一样，那在外围域的划分上必定会有肯定差别。因而，当你去做畛域划分的时候，请务必联合企业策略，这恰好也体现了 DDD 领域建模的重要性。

通过畛域划分和进一步的子域划分，咱们就能够辨别不同子域在企业内的功能属性和重要性，进而采取不同的资源投入和建设策略，这在企业 IT 零碎的建设过程中非常重要，并且这样的划分还能够帮忙企业进行中台设计。

中台的实质

中台来源于阿里的中台策略（详见钟华老师的《企业 IT 架构转型之道：阿里巴巴中台战略思想与架构实战》）。2015 年年底，阿里巴巴团体对外发表全面启动中台策略，构建合乎数字时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制，即作为前台的一线业务会更麻利、更疾速地适应瞬息万变的市场，而中台将汇合整个团体的经营数据能力、产品技术能力，对各前台业务造成强力撑持。

中台的实质其实就是提炼各个业务板块的独特需要，进行业务和零碎形象，造成通用的可复用的业务模型，打造成组件化产品，供前台部门应用。前台要做什么业务，须要什么资源，能够间接找中台，不须要每次都去改变本人的底层。

DDD、中台和微服务的合作模式

传统企业能够将须要共享的公共能力进行领域建模，建设可共享的 通用中台 。除此之外，传统企业还会将外围能力进行领域建模，建设面向不同渠道的可复用的 外围中台。

DDD 的子域分为外围域、通用域和撑持域。划分这几个子域的次要目标是为了确定策略资源的投入，一般来说策略投入的重点是外围域，因而前面咱们就能够临时不严格辨别撑持域和通用域了。

畛域、中台以及微服务尽管属于不同层面的货色，但咱们还是能够将他们合成对照，整理出来它们之间的关系。你看上面这张图，我是从 DDD 领域建模和中台建设这两个不同的视角对同一个企业的业务架构进行剖析。

如果将企业内整个业务域作为一个问题域的话，企业内的所有业务就是一个畛域。在进行畛域细分时，从 DDD 视角来看，子域可分为外围域、通用域和撑持域。从中台建设的视角来看，业务域细分后的业务中台，可分为外围中台和通用中台。

从畛域功能属性和重要性对照来看，通用中台对应 DDD 的通用域和撑持域，外围中台对应 DDD 的外围域。从畛域的性能范畴来看，子域与中台是统一的。畛域模型所在的限界上下文对应微服务。建设了这个映射关系，咱们就能够用 DDD 来进行中台业务建模了。

咱们这里还是以保险畛域为例。 保险域的业务中台分为两类：第一类是提供保险外围业务能力的外围中台（比方营销、承保和理赔等业务）；第二类是撑持外围业务流程实现保险全流程的通用中台（比方订单、领取、客户和用户等）。

这里我要揭示你一下：依据 DDD 首先要建设通用语言的准则，在将 DDD 的办法引入中台设计时，咱们要先建设中台和 DDD 的通用语言。这里的子域与中台是统一的，那咱们就能够将子域对立为中台。

中台通过事件风暴能够进一步细分，最终实现业务领域建模。中台业务畛域的性能不同，限界上下文的数量和大小就会不一样，畛域模型也会不一样。

当实现业务建模后，咱们就能够采纳 DDD 战术设计，设计出聚合、实体、畛域事件、畛域服务以及应用服务等畛域对象，再利用分层架构模型实现微服务的设计。

以上就是 DDD、中台和微服务在利用过程中的合作模式。

中台如何建模？

中台业务形象的过程就是业务建模的过程，对应 DDD 的策略设计。零碎形象的过程就是微服务的建设过程，对应 DDD 的战术设计。上面咱们就联合 DDD 领域建模的办法，讲一下中台业务建模的过程。

第一步： 依照业务流程（通常实用于外围域）或者功能属性、汇合（通常实用于通用域或撑持域），将业务域细分为多个中台，再依据功能属性或重要性归类到外围中台或通用中台。外围中台设计时要思考外围竞争力，通用中台要站在企业高度思考共享和复用能力。

第二步： 选取中台，依据用例、业务场景或用户旅程实现事件风暴，找出实体、聚合和限界上下文。顺次进行畛域合成，建设畛域模型。

因为不同中台独立建模，某些畛域对象或性能可能会反复呈现在其它畛域模型中，也有可能本该是同一个聚合的畛域对象或性能，却扩散在其它的中台里，这样会导致畛域模型不残缺或者业务不内聚。这里先不要焦急，这一步咱们只须要初步确定主畛域模型就能够了，在第三步中咱们还会提炼并重组这些畛域对象。

第三步： 以主畛域模型为根底，扫描其它中台畛域模型，查看并确定是否存在反复或者须要重组的畛域对象、性能，提炼并重构主畛域模型，实现最终的畛域模型设计。

第四步： 抉择其它主畛域模型反复第三步，直到所有主畛域模型实现比对和重构。

第五步： 基于畛域模型实现微服务设计，实现零碎落地。

联合下面这张图，你能够大抵理解到 DDD 中台设计的过程。DDD 策略设计包含上述的第一步到第四步，次要为：业务域合成为中台，对中台归类，实现领域建模，建设中台业务模型。DDD 战术设计是第五步，畛域模型映射为微服务，实现中台建设。

那么如果还是以保险畛域为例的话，实现领域建模后，外面的数据咱们就能够填上了。这里我选取了通用中台的用户、客户和订单三个中台来做示例。客户中台提炼出了两个畛域模型：客户信息和客户视图模型。用户中台提炼出了三个畛域模型：用户治理、登录认证和权限模型。订单中台提炼出了订单模型。这就是中台建模的全流程。

传统企业应用剖析

互联网电商平台和传统外围利用，两者面向的渠道和客户不一样，但销售的产品却很类似，它们之间的业务模型既有雷同的中央，又有不同的中央。

当初我拿保险行业的互联网电商和传统外围利用来做个比照剖析。咱们看一下上面这张图，这两者在业务性能上会有很多类似和差别，这种类似和差别次要体现在四个方面。

1. 外围能力的反复建设。 因为销售同质保险产品，二者在外围业务流程和性能上必然类似，因而在外围业务能力上存在性能重叠是不可避免的。传统保险外围利用有报价、投保、核保和出单功能，同样在互联网电商平台也有。这就是外围能力的反复建设。

2. 通用能力的反复建设。 传统外围利用的通用平台大而全，通常会比拟重。而互联网电商平台离不开这些通用能力的撑持，但为了放弃敏捷性，个别会本人建设放大版的通用性能，比方用户、客户等。这是通用能力的反复建设。

3. 业务职能的拆散建设。 有一类业务性能，在互联网电商平台中建设了一部分，在传统外围利用中也建设了一部分，二者性能不重叠而且还互补，组合在一起是一个残缺的业务职能。比方缴费性能，互联网电商平台次要面向集体客户，于是采纳了支付宝和微信领取的形式。而传统外围利用次要是柜台操作，仍在采纳挪动 POS 机的缴费形式。二者都是缴费，为了保障业务模型的完整性，在构建中台业务模型时，咱们能够思考将这两局部模型重组为一个残缺的业务模型。

4. 互联网电商平台和传统外围性能前后齐全独立建设。 传统外围利用次要面向柜台，不须要互联网电商平台的在线客服、话务、订单和购物车等性能。而互联网电商平台次要面向集体客户，它不须要后端比拟重的再保、佣金、打印等性能。在构建中台业务模型时，对这种状况应区别对待，将面向后端业务管理的利用积淀到后盾，将前端能力构建为面向互联网渠道的通用中台，比方订单等。

如何防止反复造轮子？

要防止反复建设，就要了解中台的理念和思维。后面说了“中台是企业级能力复用平台 ”，“ 复用”用文言说就是重复使用，就是要防止反复造轮子的事件。

中台的设计思维与“高内聚、低耦合”的设计准则是高度一致的。高内聚是把相干的业务行为汇集在一起，把不相干的行为放在其它中央，如果你要批改某个业务行为，只须要批改一处。对了！中台就是要这样做，依照“高内聚、松耦合”的准则，实现企业级的能力复用！

那如果你的企业遇到了反复造轮子的状况，应该怎么解决？

你须要站在企业高度，将反复的须要共享的通用能力、外围能力积淀到中台，将拆散的业务能力重组为残缺的业务板块，构建可复用的中台业务模型。前端共性能力归前端，后端治理能力归后盾。建设前、中、后盾边界清晰，交融合作的企业级可复用的业务模型。

如何构建中台业务模型？

咱们能够用 DDD 领域建模的办法来构建中台业务模型。你能够抉择两种建模策略：自顶向下和自底向上的策略。具体采纳哪种策略，你须要联合公司的具体情况来剖析，上面我就来介绍一下这两种策略。

1. 自顶向下的策略

第一种策略是自顶向下。这种策略是先做顶层设计，从最高畛域逐级分解为中台，别离建设畛域模型，依据业务属性分为通用中台或外围中台。领域建模过程次要基于业务现状，临时不思考零碎现状。自顶向下的策略实用于全新的利用零碎建设，或旧零碎推倒重建的状况。

因为这种策略不用受限于现有零碎，你能够用 DDD 畛域逐级分解的领域建模办法。从上面这张图咱们能够看出它的次要步骤：第一步是将畛域合成为子域，子域能够分为外围域、通用域和撑持域；第二步是对子域建模，划分畛域边界，建设畛域模型和限界上下文；第三步则是依据限界上下文进行微服务设计。

2. 自底向上的策略

第二种策略是自底向上。这种策略是基于业务和零碎现状实现领域建模。首先别离实现零碎所在业务域的领域建模；而后对齐业务域，找出具备同类或类似业务性能的畛域模型，比照剖析畛域模型的差别，重组畛域对象，重构畛域模型。这个过程会积淀公共和复用的业务能力，会将扩散的业务模型整合。自底向上策略实用于遗留零碎业务模型的演进式重构。

上面我以互联网电商和传统外围利用的几个典型业务域为例，带你理解具体如何采纳自底向上的策略来构建中台业务模型，次要分为这样三个步骤。

第一步：锁定零碎所在业务域，构建畛域模型。

锁定零碎所在的业务域，采纳事件风暴，找出畛域对象，构建聚合，划分限界上下文，建设畛域模型。看一下上面这张图，咱们选取了传统外围利用的用户、客户、传统收付和承保四个业务域以及互联网电商业务域，共计五个业务域来实现领域建模。

从下面这张图中，咱们能够看到传统外围共构建了八个畛域模型。其中用户域构建了用户认证和权限两个畛域模型，客户域构建了集体和个人两个畛域模型，传统收付构建了 POS 刷卡畛域模型，承保域构建了定报价、投保和保单治理三个畛域模型。

互联网电商构建了报价、投保、订单、客户、用户认证和挪动收付六个畛域模型。

在这些畛域模型的清单里，咱们能够看到二者之间有很多名称类似的畛域模型。深入分析后你会发现，这些名称类似的畛域模型存在业务能力反复，或者业务职能扩散（比方挪动领取和传统领取）的问题。那在构建中台业务模型时，你就须要重点关注它们，将这些不同畛域模型中反复的业务能力积淀到中台业务模型中，将扩散的畛域模型整合到对立的中台业务模型中，对外提供对立的共享的中台服务。

第二步：对齐业务域，构建中台业务模型。

在上面这张图里，你能够看到右侧的传统外围畛域模型显著多于左侧的互联网电商，那咱们是不是就能够得出一个初步的论断：传统外围面向企业内大部分利用，大而全，畛域模型绝对齐备，而互联网电商面向繁多渠道，畛域模型绝对繁多。

这个论断也给咱们指明了一个方向：首先咱们能够将传统外围的畛域模型作为主畛域模型，将互联网电商畛域模型作为辅助模型来构建中台业务模型。而后再将互联网电商中反复的能力积淀到传统外围的畛域模型中，只保留本人的共性能力，比方订单。中台业务建模时，既要关注畛域模型的齐备性，也要关注不同渠道麻利响应市场的要求。

有了上述这样一个思路，咱们就能够开始构建中台业务模型了。

咱们从互联网电商和传统外围的畛域模型中，演绎并拆散出能笼罩两个域的所有业务子域。通过剖析，咱们找到了用户、客户、承保、收付和订单五个业务域，它们是能够用于畛域模型比照剖析的基准域。

上面我以客户为例，来给你讲一下客户中台业务模型的构建过程。

互联网电商客户次要面向集体客户，除了有集体客户信息管理性能外，基于营销目标它还有客户积分性能，因而它的畛域模型有集体和积分两个聚合。

而传统外围客户除了反对集体客户外，还有单位和组织机构等个人客户，它有集体和个人两个畛域模型。其中集体畛域模型中除了集体客户信息管理性能外，还有集体客户的评级、反复客户的归并和客户的对立视图等性能，因而它的畛域模型有集体、视图、评级和归并四个聚合。

构建多业务域的中台业务模型的过程，就是找出同一业务域内所有同类业务的畛域模型，比照剖析域内畛域模型和聚合的差别和共同点，突破原有的模型，实现新的中台业务模型重组或归并的过程。

咱们将互联网电商和传统外围的畛域模型合成后，咱们找到了五个与集体客户畛域相干的聚合，包含：集体、积分、评级、归并和视图。这五个聚合原来别离扩散在互联网电商和传统外围的畛域模型中，咱们须要突破原有的畛域模型，进行性能积淀和聚合的重组，从新找出这些聚合的限界上下文，重构畛域模型。

最终集体客户的畛域模型重构为： 集体、归并和视图三个聚合重构为集体畛域模型（客户信息管理），评级和积分两个聚合重构为评级积分畛域模型（面向集体客户）。到这里咱们就实现了集体客户畛域模型的构建了。

如同还漏掉点什么货色呢？对了，还有团队客户畛域模型！其实个人客户很简略。因为它只在传统外围中呈现，咱们将它在传统外围中的畛域模型间接拿过去用就行了。

至此咱们就实现了客户中台业务模型的构建了，客户中台构建了集体、个人和评级积分三个畛域模型。

通过客户中台业务模型的构建，你是否 get 到构建中台业务模型的要点了呢？总结成一句话就是：“分域建模型，找准基准域，划定上下文，聚合重归类。”

第三步：中台归类，依据畛域模型设计微服务。

实现中台业务建模后，咱们就有了上面这张图。从这张图中咱们能够看到总共构建了多少个中台，中台上面有哪些畛域模型，哪些中台是通用中台，哪些中台是外围中台，中台的根本信息等等，都高深莫测。你依据中台下的畛域模型就能够设计微服务了。

重构过程中的畛域对象

下面次要是从聚合的角度来形容中台业务模型的重组，是绝对高阶的业务模块的重构。业务模型重构和聚合重组，往往会带来畛域对象和业务行为的变动。上面我带你理解一下，在畛域模型重组过程中，产生在更底层的畛域对象的流动。

咱们还是以客户为例来讲述。因为对象过多，我只选取了局部畛域对象和业务行为。

传统外围客户畛域模型重构之前，蕴含集体、个人和评级三个聚合，每个聚合外部都有本人的聚合根、实体、办法和畛域服务等。

互联网电商客户畛域模型重构前蕴含集体和积分两个聚合，每个聚合蕴含了本人的畛域对象、办法和畛域服务等。

传统外围和互联网电商客户畛域模型重形成客户中台后，建设了集体、个人和评级积分三个畛域模型。其中集体畛域模型有集体聚合，个人畛域模型有个人聚合，评级积分畛域模型有评级和积分两个聚合。这些畛域模型的畛域对象来自原来的畛域模型，但积分评级是重组后的畛域模型，它们原来的聚合会带着各自的畛域对象，退出到新的畛域模型中。

这里还要留神：局部畛域对象可能会依据新的业务要求，从原来的聚合中拆散，重组到其它聚合。新畛域模型的畛域对象，比方实体、畛域服务等，在重组后可能还会依据新的业务场景和需要进行代码重构。

总结

明天咱们次要探讨了传统企业中台建设的一些思路，梳理了 DDD、中台和微服务的关系。DDD 的策略设计可用于中台业务建模，战术设计可领导中台微服务设计。紧接着咱们一起探讨了传统企业中台数字化转型，在面对多个不同渠道利用反复建设时，如何用 DDD 领域建模的思维来构建中台业务模型。中台业务建模有自顶向下和自底向上两种策略，这两种策略有本人的实用场景，你须要联合本人公司的状况抉择适合的策略。中台业务模型的重构过程，也是微服务架构演进的过程。业务边界即微服务边界，业务边界做好了，微服务的边界天然就会很好。

本文由 mdnice 多平台公布