进入 21 世纪，互联网应用迅猛发展，众多传统企业纷纷 “触网”，搭建起自己的互联网电商平台。随后，微信、App 等移动互联应用强势崛起，掀起了新一轮的移动应用热潮。
这些移动互联应用，大多面向个人用户或第三方，市场需求瞬息万变，这就要求它们必须以敏捷的速度适应市场的变化。为了满足快速响应与频繁发版的需求，许多移动互联网应用选择独立于传统核心系统进行建设。然而，两者承载的业务大多相似，这就极易导致业务能力出现重叠。
阿里巴巴曾引领传统企业向互联网电商转型。如今，时代进入新的历史时期，在阿里巴巴提出中台战略后，众多企业紧随其后，高举中台大旗，轰轰烈烈地踏上数字化转型之路。那么，传统企业在中台转型过程中，如何从错综复杂的业务里构建中台业务模型呢？今天，我将通过一个传统企业中台建模的案例，带你运用 DDD 的设计思想，一同构建中台业务模型。
传统企业应用分析
互联网电商平台和传统核心应用，两者面向的渠道和客户不一样，但销售的产品却很相似，它们之间的业务模型既有相同的地方，又有不同的地方。现在我拿保险行业的互联网电商和传统核心应用来做个对比分析。
我们看一下下面这张图，这两者在业务功能上会有很多相似和差异，这种相似和差异主要体现在四个方面。
图片
1.核心能力的重复建设
以保险行业为例，当传统保险核心应用与互联网电商平台销售同质保险产品时，二者在核心业务流程和功能上呈现出相似性。传统保险核心应用具备报价、投保、核保和出单等功能，互联网电商平台同样也有这些功能。这就导致在核心业务能力上不可避免地出现功能重叠，造成资源浪费和管理成本增加。
2.通用能力的重复建设
传统核心应用的通用平台通常规模庞大、功能齐全，但也较为笨重。互联网电商平台虽然依赖这些通用能力，但为了保持自身的敏捷性，往往会自行搭建缩小版的通用功能，例如用户管理、客户管理等。这种重复建设不仅耗费人力、物力，还使得企业内部系统架构变得更为复杂。
3.业务职能的分离建设
部分业务功能在互联网电商平台和传统核心应用中分别建设，且二者功能互补，共同构成完整的业务职能。以缴费功能来说，互联网电商平台主要面向个人客户，多采用支付宝和微信支付等便捷方式；而传统核心应用主要在柜台操作，依旧使用移动 POS 机缴费。为了确保业务模型的完整性，在构建中台业务模型时，可考虑将这两部分进行重组，形成一个完整的业务模型。
4.前后端完全独立建设
传统核心应用主要服务于柜台业务，因此并不需要互联网电商平台所具备的在线客服、话务、订单和购物车等功能；而互联网电商平台主要面向个人客户，也无需后端较为复杂的再保、佣金、打印等功能。在构建中台业务模型时，针对这种情况，应当区别对待，将面向后端业务管理的应用沉淀到后台，把前端能力构建成面向互联网渠道的通用中台，如订单中台等。这样的处理方式能够有效整合资源，提升企业的整体运营效率。
如何避免重复造轮子？
要有效避免企业内部的重复建设，关键在于深入理解中台的理念和思想。我们常说 “中台是企业级能力复用平台”，这里的 “复用” 通俗来讲，就是重复使用，目的就是防止做重复造轮子这种浪费资源的事。
中台的设计思想与 “高内聚、低耦合” 的设计原则高度契合。所谓高内聚，就是把相关的业务行为集中整合在一起，不相关的行为则安排到其他地方。这样一来，要是需要修改某个业务行为，只需在一处进行修改即可。没错，中台就该遵循 “高内聚、松耦合” 的原则，实现企业级的能力复用。
那当企业遇到重复造轮子的情况时，该如何应对呢？这就需要站在企业整体的高度去考量，将那些重复的、需要共享的通用能力和核心能力沉淀到中台。同时，把分散的业务能力重新组合，形成完整的业务板块，以此构建可复用的中台业务模型。具体来说，前端的个性化能力就归前端负责，后端的管理能力则由后台承担。通过这种方式，建立起前、中、后台边界清晰，又能相互融合协作的企业级可复用业务模型，从而提升企业整体的运营效率和资源利用率，避免不必要的重复建设。
如何构建中台业务模型？
我们可以用 DDD 领域建模的方法来构建中台业务模型。你可以选择两种建模策略：自顶向下和自底向上的策略。具体采用哪种策略，你需要结合公司的具体情况来分析，下面我就来介绍一下这两种策略。
1. 自顶向下的策略
在企业数字化转型进程中，有效规避重复建设是提升效率、节约资源的关键，而这离不开对中台理念与思想的深度领会。中台被定义为 “企业级能力复用平台”，“复用” 即重复使用，旨在杜绝重复造轮子这类资源浪费现象。
中台设计思想与 “高内聚、低耦合” 原则紧密相连。高内聚是将关联业务行为整合一处，无关行为放置别处，这使得业务行为修改只需在一处操作，十分便捷。中台正是遵循 “高内聚、松耦合” 原则，达成企业级能力复用。
当企业面临重复造轮子问题时，需从企业整体视角出发，将重复且需共享的通用能力、核心能力沉淀到中台，整合分散的业务能力，构建可复用的中台业务模型。具体而言，前端负责个性化能力，后端承担管理能力，构建前、中、后台边界明晰且协同合作的企业级可复用业务模型，提升运营效率，避免重复建设。
下面介绍第一种策略 —— 自顶向下。这种策略的核心是先开展顶层设计，从最高领域逐步细化分解至中台，并分别构建领域模型。依据业务属性，中台又可分为通用中台和核心中台。在领域建模阶段，主要依据业务实际状况进行，暂不考虑现有系统。自顶向下策略适用于全新应用系统开发，或是旧系统全面重构的情形。由于不受现有系统的制约，可采用 DDD 领域逐级分解的领域建模方法。主要步骤如下：
- 领域分解：把领域拆分为子域，子域包含核心域、通用域和支撑域。
- 子域建模：对各子域进行建模，明确领域边界，构建领域模型和限界上下文。
- 微服务设计：依据限界上下文进行微服务设计。
图片
2. 自底向上的策略
在阐述完自顶向下的策略后，下面为你介绍第二种策略 —— 自底向上。这种策略的特点是紧密依托业务和系统的当前实际状况来开展领域建模工作。
其具体实施过程如下：首先，针对每个系统所处的业务域分别进行全面的领域建模。在这个过程中，深入剖析各个业务域的业务流程、规则以及数据关系等，从而构建出相对独立的领域模型。接着，进行业务域对齐操作，即仔细甄别出那些具有相同或相似业务功能的领域模型。通过对比分析这些模型之间的差异，对领域对象进行重新组合，进而对领域模型进行重构。在这一过程中，能够有效沉淀出公共的、可复用的业务能力，同时将原本分散的业务模型进行有机整合 ，形成更为高效、统一的业务架构。
自底向上策略尤其适用于遗留系统业务模型的演进式重构。通过这种方式，能够充分利用现有系统的资源，在不进行大规模推倒重建的基础上，逐步优化和完善业务模型，降低系统改造的风险和成本。
接下来，我将以互联网电商和传统核心应用的几个典型业务域为实例，详细为你讲解如何运用自底向上的策略来构建中台业务模型，主要分为以下三个步骤。
第一步：锁定系统所在业务域，构建领域模型。
锁定系统所在的业务域，采用事件风暴，找出领域对象，构建聚合，划分限界上下文，建立领域模型。看一下下面这张图，我们选取了传统核心应用的用户、客户、传统收付和承保四个业务域以及互联网电商业务域，共计五个业务域来完成领域建模。
图片
从上述示意图中，我们能够清晰地看到，传统核心系统共构建了八个领域模型。在用户域，搭建了用户认证和权限这两个领域模型；客户域则构建了个人与团体两个领域模型；传统收付领域构建了 POS 刷卡领域模型；承保域构建了定报价、投保和保单管理三个领域模型。而互联网电商构建了报价、投保、订单、客户、用户认证和移动收付六个领域模型。
对比这些领域模型清单，不难发现，传统核心系统与互联网电商之间存在诸多名称相似的领域模型。经过深入分析会发现，这些看似相似的领域模型，实则存在业务能力重复的情况，或者像移动支付与传统支付这样，业务职能处于分散状态。
基于此，在构建中台业务模型时，我们就需要重点聚焦这些领域模型。将不同领域模型中重复的业务能力，精准沉淀到中台业务模型中，同时把分散的领域模型整合为统一的中台业务模型，最终对外提供统一且共享的中台服务。如此一来，便能有效提升企业资源的利用效率，减少重复建设带来的资源浪费，推动企业数字化转型的顺利进行。
第二步：对齐业务域，构建中台业务模型。
从这张图中，我们能直观地发现，右侧传统核心的领域模型数量明显多于左侧互联网电商的领域模型。由此，我们可以初步推断：传统核心主要面向企业内部的大部分应用，追求全面覆盖，所以其领域模型相对完备；而互联网电商仅面向单一渠道，领域模型相对单一。
这一结论为我们构建中台业务模型提供了方向。我们可以将传统核心的领域模型作为构建中台业务模型的主要依据，把互联网电商领域模型当作辅助。具体来说，先把互联网电商中重复的能力整合到传统核心的领域模型中，互联网电商则仅保留像订单这类个性化能力。
在中台业务建模过程中，我们不仅要注重领域模型的完备性，以确保业务的全面支持；还要充分考虑不同渠道对市场的敏捷响应需求，使中台既能承载丰富的业务功能，又能灵活应对市场变化，从而提升企业整体的竞争力和运营效率，有力推动企业数字化转型进程。
图片
基于已有的构建中台业务模型思路，我们正式开启构建之旅。首先，从互联网电商和传统核心的领域模型入手，归纳并分离出能够覆盖这两个域的全部业务子域。经过深入分析，我们确定了用户、客户、承保、收付和订单这五个业务域，它们将作为领域模型对比分析的基准域。
接下来，我以客户业务域为例，详细阐述客户中台业务模型的构建过程。互联网电商的客户主要面向个人客户，除了具备个人客户信息管理功能，出于营销目的，还设有客户积分功能。所以，其领域模型包含个人和积分两个聚合。反观传统核心客户，不仅支持个人客户，还涵盖单位和组织机构等团体客户，拥有个人和团体两个领域模型。在个人领域模型中，除个人客户信息管理功能外，还涉及个人客户的评级、重复客户的归并以及客户的统一视图等功能，对应个人、视图、评级和归并四个聚合。
构建多业务域中台业务模型的关键在于，找出同一业务域内所有同类业务的领域模型，对域内领域模型和聚合的差异与共同点展开对比分析，突破原有的模型框架，完成新中台业务模型的重组或归并。我们将互联网电商和传统核心的领域模型进行分解后，发现了五个与个人客户领域相关的聚合，分别是个人、积分、评级、归并和视图。这些聚合原本分散在不同的领域模型中，现在需要打破原有的领域模型限制，进行功能沉淀和聚合的重新组合，重新确定这些聚合的限界上下文，进而重构领域模型。最终，个人客户的领域模型重构如下：将个人、归并和视图三个聚合重构成个人领域模型，主要负责客户信息管理；评级和积分两个聚合重构成评级积分领域模型，主要面向个人客户。到这里，个人客户领域模型构建完成。
等等，似乎还有遗漏。没错，还有团体客户领域模型！实际上，团体客户相对简单，因为它仅在传统核心中出现，我们直接将其在传统核心中的领域模型拿来使用即可。至此，我们成功完成了客户中台业务模型的构建，该中台包含个人、团体和评级积分三个领域模型。
通过这次客户中台业务模型的构建过程，你是否掌握了构建中台业务模型的要点呢？简单总结就是：“分域建模型，找准基准域，划定上下文，聚合重归类。” 其他业务域的构建过程亦是如此，这里就不再逐一赘述。大家可以自行练习，将其作为课后作业。完成后，可对照下面这张图进行检查，这是其他业务域重构后的中台业务模型。
图片
第三步：中台归类，根据领域模型设计微服务。
完成中台业务建模后，我们就有了下面这张图。从这张图中我们可以看到总共构建了多少个中台，中台下面有哪些领域模型，哪些中台是通用中台，哪些中台是核心中台，中台的基本信息等等，都一目了然。你根据中台下的领域模型就可以设计微服务了。
图片
重构过程中的领域对象
上面主要是从聚合的角度来描述中台业务模型的重组，是相对高阶的业务模块的重构。业务模型重构和聚合重组，往往会带来领域对象和业务行为的变化。下面我带你了解一下，在领域模型重组过程中，发生在更底层的领域对象的活动。我们还是以客户为例来讲述。由于对象过多，我只选取了部分领域对象和业务行为。传统核心客户领域模型重构之前，包含个人、团体和评级三个聚合，每个聚合内部都有自己的聚合根、实体、方法和领域服务等。
图片
互联网电商客户领域模型重构前包含个人和积分两个聚合，每个聚合包含了自己的领域对象、方法和领域服务等。
图片
将传统核心和互联网电商的客户领域模型重构成客户中台后，形成了个人、团体和评级积分这三个领域模型。其中，个人领域模型包含个人聚合，团体领域模型包含团体聚合，评级积分领域模型则由评级和积分两个聚合组成。
这些新领域模型的领域对象都源自原有的领域模型。不过，评级积分是经过重组产生的领域模型，原有的聚合会带着各自的领域对象融入新的领域模型中。值得注意的是，根据新的业务要求，部分领域对象可能会从原聚合中分离出来，重新组合到其他聚合里。
此外，新领域模型中的领域对象，如实体、领域服务等，在完成重组后，可能还需要依据新的业务场景和需求进行代码重构。通过这样的操作，能让新领域模型更好地适应业务发展，为企业的数字化转型提供更有力的支持。
图片
