如何用DDD重构中台业务模型
进入2000年后，随着互联网应用的快速发展，很多传统企业开始触网，建设了自己的互联网电商平台。后来又随着微信和App等移动互联应用的兴起，掀起了新一轮的移动应用热潮。
这些移动互联应用大多面向个人或者第三方，由于市场和需求变化快，它们需要以更敏捷的速度适应市场的快速变化。为了满足快速响应能力和频繁的版本发布要求，这些移动互联应用大多是独立于传统核心系统建设的。但移动互联和传统核心应用两者承载的业务大多又是同质的，因此就很容易出现重复建设的问题。
阿里巴巴过去带动了传统企业向互联网电商转型。而如今又到了一个新的历史时期，在阿里巴巴提出中台战略后，很多企业又紧跟它的步伐，高举中台大旗，轰轰烈烈地开始了数字化转型之路。
那么传统企业在中台数字化转型时，应该如何从错综复杂的业务中，构建出企业级可复用的中台业务模型？又该如何减少系统重复建设呢？
传统企业应用建设分析
传统企业在建设互联网电商平台和传统核心应用时，虽然两者定位不一样，面向的渠道和客户也不一样，但销售的产品却大多是同质的。所以，它们的业务模型既有相同的地方，又有不同的地方。
现在我以保险行业的互联网电商和传统核心应用为例进行对比分析，由于两者都面向同类产品的销售业务场景，所以它们在业务功能上会有很大的相似性。同时它们又面向不同的用户和客户，所以在实现方式上又会有很大的差异。两者的相似和差异主要体现在四个方面。
- 核心能力的重复建设
由于销售同质的产品，所以二者在核心业务流程和功能建设时必然会有相似性，在核心业务能力上存在功能重叠在所难免。传统保险核心应用有报价、投保、核保和出单功能，同样在互联网电商平台也有这些功能。
- 通用能力的重复建设
传统企业一般都会有用户、客户、数据字典等这些通用的功能。
传统核心应用的这些通用能力平台，一般来说功能大而全，所以会比较重。互联网电商平台同样也离不开这些通用能力的支撑，但为了保持应用的敏捷性，一般都会有缩小版的通用功能，比如用户和客户等通用能力。
- 同一业务领域的职能分离
还有一类业务功能，在互联网电商平台中建设了一部分功能，在传统核心应用中也建设了一部分功能，二者功能独立而且互补。它们属于同一个业务领域，只不过被分散到了不同的渠道应用中建设。如果将这些业务功能组合在一起，它们就可以组合为某一个业务领域的完整领域模型。
比如，同样的支付功能，由于互联网电商平台主要面向个人客户，于是采用了支付宝和微信的互联网化的支付方式。而传统保险核心应用主要面向柜台用户，仍旧在用移动POS机刷卡的缴费方式。它们都属于收付业务领域的领域模型，却被分散到了不同的渠道应用中。
对于这种场景，我们在构建收付中台领域模型时，可以考虑将它们的业务能力重组，以保证领域模型的完整性。这也是我们在中台领域建模过程中需要重点解决的问题。
- 完全独立的业务领域
传统核心应用主要面向柜台内部用户，没有互联网电商平台的在线客服、话务、订单和购物车等功能。而互联网电商平台主要面向外部个人客户，它不需要打印等功能。
在构建中台业务模型时，对这种情况我们需要区别对待。将前台能力构建为面向所有前台渠道应用的通用能力中台，比如购物车、订单等；将面向后端业务管理职能的应用后移到后台。
如何避免重复造轮子
要避免重复建设，先要理解中台的核心理念和设计思想。
前面说了"中台是企业级能力复用平台"，"复用"用白话来说其实就是重复使用，就是要避免干重复造轮子的事情。
中台设计思想与"高内聚，低耦合"的设计原则是高度一致的。
"高内聚，松耦合"就是把相关的业务行为聚集在一起，把不相关的业务行为放在其他地方，如果你要修改某个业务行为，只需要修改一处就可以了。中台也是要这样做！按照"高内聚，松耦合"的设计原则，实现企业级的能力复用！
那么，如果你的企业遇到了重复造轮子的问题，应该怎么处理？
你需要站在企业高度，将重复的、需要共享的通用能力、核心能力沉淀到业务中台。将分散在各个不同业务板块的业务能力重组为完整的业务板块，构建可复用的中台业务模型。让前台通用能力归前台，后台管理能力归后台。建立前、中、后台边界清晰，融合协作的企业级可复用的中台领域模型。
如何构建中台业务模型
我们可以用DDD战略设计的方法来构建中台业务模型。这里有两种领域建模策略：自顶向下的策略和自底向上的策略。具体采用哪种策略，需要结合企业的具体情况来分析和选择。
[]
### 自顶向下的策略
第一种策略是自顶向下建模策略。这种策略是先做顶层设计，从最高级领域逐级分解为不同的子域，即中台，分别构建领域模型，根据领域属性和重要性将中台分为通用中台或核心中台。
自顶向下的领域建模过程主要基于业务现状和企业未来战略目标，不过多考虑系统建设现状。所以它比较适合全新的应用系统建设，或遗留系统推倒重建的建设模式。
由于这种策略不必受限于现有系统，你可以采用DDD领域逐级分解的领域建模方式。该建模方式主要分为三个关键步骤。
第一步，根据核心业务流程或功能边界，将领域分解为不同子域，子域根据不同的属性可以分为核心子域、通用子域和支撑子域。
第二步，对子域建模，划分限界上下文边界，建立领域模型。
第三步，根据限界上下文边界完成微服务拆分。
### 自底向上的策略
第二种策略是自底向上建模策略。这种策略基于业务和系统建设现状来重构中台领域模型。自底向上策略在领域建模时，将系统所在业务领域的公共和重复建设的业务能力沉淀到中台，进行抽象和标准化处理后，完成领域模型重构。
自底向上策略比较适合遗留系统领域模型的演进式重构，因此也适合单体应用向微服务架构演进。
在用自底向上策略完成领域模型重构后，我们就可以基于这些重构后的通用领域模型完成微服务设计和建设，然后用新的服务逐步替换掉原来分散在不同遗留单体应用中的能力。
下面我以互联网电商和传统核心应用的几个典型业务子域作为示例，带你了解如何采用自底向上的策略来构建中台业务模型。
这个过程主要分为以下三个关键步骤。
第一步，锁定业务领域，构建领域模型
锁定应用所在的业务领域，采用事件风暴方法，找出领域对象，构建聚合，划分限界上下文，建立领域模型。
这里我们选取了传统核心应用的用户、客户、传统收付和承保四个业务领域以及互联网电商业务领域，共计五个业务领域，分别完成领域建模。
你可以按照事件风暴方法，逐一完成各应用所在业务领域的领域建模。
我们可以看到在传统核心业务领域（包括用户域、客户域、传统收付域和承保域四个子域）共构建了八个领域模型。其中用户域构建了用户认证和权限两个领域模型，客户域构建了个人和团体两个领域模型，传统收付域构建了POS刷卡领域模型，承保域构建了定报价、投保和保单管理三个领域模型。
而在互联网电商业务领域共构建了报价、投保、订单、客户、用户认证和移动收付六个领域模型。
从这些领域模型中，我们可以看到传统核心和互联网电商的领域模型中有很多名称相似的领域模型和对象。深入分析后你就会发现，这些名称相似的领域模型其实就是可能存在能力重复建设的业务领域，或者存在业务领域能力分散建设（比如移动支付和传统支付）的领域。
我们在构建中台业务模型时，需要重点关注这些领域。将存在于不同领域模型中的重复的业务能力进行重构和抽象后，沉淀到中台业务模型。将分散的领域对象整合到统一的中台领域模型中，构建企业级的中台领域模型，提供可复用的中台服务。
第二步，对准基准域，重构中台领域模型
我们可以看到在传统核心领域模型，明显比互联网电商领域模型的内容更丰富。那么，我们是不是就可以得到一个初步的结论："传统核心由于面向企业内大部分渠道和业务场景，所以功能大而全，因此领域模型也相对完备。而互联网电商由于主要面向外部客户和单一渠道，所以领域模型相对单一。"
这个结论也给我们指明了一个领域模型重构的方向。
首先我们可以将传统核心的领域模型作为主领域模型，将互联网电商领域模型作为辅助模型来构建中台业务模型。然后可以将互联网电商中重复的能力沉淀到传统核心的领域模型中，只保留自己独有的个性业务领域模型，比如订单等。这样构建出来的领域模型就可以同时适应企业内所有业务领域，达到业务能力复用的目的。
有了上面的思路，我们就可以开始重构中台业务模型了。
我们可以从互联网电商和传统核心的领域模型中，归纳并分离出能够同时覆盖互联网电商和传统核心两大业务领域的所有业务子域，即基准域。
通过分析，我们找出了用户、客户、承保、收付和订单五个相对独立的业务子域，它们可以作为互联网电商和传统核心领域模型对比和分析的基准域。定义好了基准域，我们就可以继续完成互联网电商和传统核心两者领域模型的对比和分析，按照基准域重构领域模型。
使用自底向上策略重构中台业务模型的过程，跟事件风暴一样，也是一个从发散到收敛的过程。它首先针对系统的业务领域分别构建领域模型，然后分析这些业务领域的领域模型，经过抽象和归纳找出基准域。接着找出基准域可能覆盖的所有领域模型，对比分析这些领域模型和聚合内领域对象的差异。然后抽象和提炼领域模型，完成领域对象重组，收敛并重构出"高内聚，低耦合"的、可复用的标准中台领域模型。
在企业业务领域中，客户是一个非常重要的业务子域，在互联网电商和传统核心同时存在客户相关的领域模型。我们将客户子域确定为企业内客户业务领域的基准域，它同时需要覆盖互联网电商和传统核心客户相关的业务能力。
客户基准域领域模型的重构，就是将这些分散在互联网电商和传统核心客户相关的领域对象进行抽象和重组，完成客户中台领域模型重构的过程。重构后的客户领域模型可以同时满足互联网电商和传统核心等不同渠道应用所有客户相关的能力要求，从而实现客户业务能力的复用。
下面我以客户子域为例，讲解客户中台领域模型的构建过程。
互联网电商客户域主要面向个人客户，除了支持个人客户信息管理功能外，基于营销目的，它还会支持客户积分等功能，因此在互联网电商客户领域模型有个人客户和积分两个聚合。
而传统核心客户域除了支持个人客户外，还有单位和组织机构等团体客户，因此它有个人和团体两个领域模型。其中个人客户领域模型中除了支持个人客户信息管理功能外，还支持个人客户评级、重复客户归并和客户统一视图等功能，因此传统核心的个人客户领域模型会有个人客户、视图、评级和归并四个聚合。
我们将互联网电商和传统核心的客户领域模型按照聚合分解后，就可以找到五个与个人客户领域相关的聚合，如：个人客户、积分、评级、客户归并和客户视图等。这五个聚合分散在互联网电商和传统核心的客户领域模型中。在客户领域模型重构时，我们需要打破它们原有的上下文边界和领域模型，在客户基准域内进行功能沉淀和聚合重组，重新划分这些聚合的限界上下文边界，重构客户领域模型。
个人客户、归并和客户视图三个聚合属于客户基本信息管理限界上下文，我们可以将它们重构为个人客户领域模型，主要管理客户基本信息。
评级和积分两个聚合则属于个人客户评级积分管理限界上下文，我们将这两个聚合重构为面向个人客户的评级积分领域模型。
到这里，我们就从互联网电商和传统核心客户域的五个聚合中，重构出了个人客户和评级积分两个新的个人客户领域模型，完成了个人客户领域模型的重构。
好像还漏掉点什么东西？是的，客户域的领域模型应该还有团体客户的领域模型！
其实团体客户很简单。由于它只在传统核心客户域中出现，所以我们直接使用它在传统核心中的领域模型即可，如果团体客户功能未来需要扩展到互联网电商业务领域，我们只需要在现有团体客户领域模型的基础上完成演进就可以了。
至此我们就完成了客户基准域中台领域模型的重构了。
最后我们为客户中台构建了个人、团体和评级积分三个领域模型，这三个领域模型可以作为企业级客户标准解决方案，面向企业所有领域实现客户能力复用。
通过客户中台业务模型的构建，你是否理解了构建中台业务模型的要点了呢？
自底向上中台业务模型构建的过程，总结成一句话就是："分域建模型，找准基准域，划分上下文，聚合重归类。"其他业务领域模型重构的过程与此基本类似，这里不再赘述。
第三步，中台归类，完成微服务设计
完成所有基准域的中台业务建模后，我们就可以根据这些中台的属性和重要性，将它们区分并归类为核心中台和通用中台。
业务模型重构过程中的领域对象
上文主要是从聚合的拆分和合并角度，来描述中台业务模型的重构过程，是相对高阶维度的业务功能单元的重构。领域模型在重构和聚合重组的过程中，往往会由于不同业务场景的复用考虑，而需要进行领域对象和业务行为的抽象处理。比如将某些个性的业务行为，抽象和标准化为可复用的、统一的标准业务行为。
下面我将带你了解在领域模型重组过程中发生在更底层的领域对象的活动。还是以客户为例，由于领域对象过多，我只选取了部分领域对象和业务行为。
前文提过，传统核心客户领域模型包含个人客户、团体客户和评级三个聚合，每个聚合内部都有自己的领域对象，如聚合根、实体和值对象等。
互联网电商客户领域模型包含个人客户和积分两个聚合，每个聚合也都有自己的领域对象。
传统核心和互联网电商客户领域重构为企业级客户中台后，建立了个人、团体和评级积分三个领域模型。其中个人领域模型有个人客户聚合，团体领域模型有团体客户聚合，评级积分领域模型有评级和积分两个聚合。
这些领域模型的领域对象分别来自于传统核心和互联网电商的领域模型。积分评级是重构后的领域模型，原来的评级和积分聚合会分别带着各自的领域对象，加入新的领域模型中。
部分领域对象可能会根据复用和领域模型完整性要求，从它原来的聚合中抽离，重组到新的聚合。重组后的新领域模型中的领域对象，比如实体属性、方法等，可能还会根据业务场景和需求进行代码标准化处理，以满足企业级复用要求。
小结
中台业务建模时，既要关注企业级领域模型的完备性，也要关注领域模型重构后，能够同时面向企业所有业务场景无差异地实现能力复用。既要满足传统业务场景需求，又要在移动互联场景中也能保持敏捷的市场响应能力。
其实，中台业务模型的重构过程，也是微服务架构演进的过程。业务边界即微服务边界，业务边界划分清楚了，微服务的边界和职责自然就明确了。