在探讨传统企业与阿里巴巴中台战略的差异时，我们发现大多数企业仍然倾向于采用传统的中台建设模式。这种模式的核心在于将通用能力与核心能力全面中台化，以实现不同渠道间核心业务能力的复用。因此，我们的讨论重点将回归到传统企业的中台建设上。
传统企业通常会将需要共享的公共能力进行领域建模，从而构建出可共享的通用中台。同时，它们也会对核心能力进行领域建模，以建设面向不同渠道的可复用核心中台。这些通用中台和核心中台，都属于我们之前提到的业务中台的范畴。
在领域驱动设计（DDD）中，子域被划分为核心域、通用域和支撑域。这种划分的主要目的是为了明确战略资源的投入方向。通常，战略投入的重点会放在核心域上，因此在实际操作中，我们可以不必严格区分支撑域和通用域。
尽管领域、中台以及微服务属于不同层面的概念，但我们仍然可以将它们进行分解和对照，梳理出它们之间的关系。例如，在下面的图表中，我分别从DDD领域建模和中台建设两个不同的视角，对同一企业的业务架构进行了分析。
将企业内部的整个业务域视为一个广泛的问题域，那么企业内的所有业务活动便构成了一个统一的领域。在深入领域细分的实践中，从领域驱动设计（DDD）的角度出发，子域可以被细致划分为核心域、通用域和支撑域。而从中台建设的视角审视，业务域经过细分后形成的业务中台，则可分为核心中台与通用中台。将领域的功能属性与重要性进行对照，可以发现通用中台与DDD中的通用域和支撑域相对应，而核心中台则与DDD的核心域相呼应。从领域的覆盖范围来看，子域与中台的范围是一致的。领域模型所依托的限界上下文，则与微服务相对应。通过建立这样的映射关系，我们便能运用DDD的方法来进行中台业务建模。
以保险领域为例，保险域的业务中台可分为两大类：一类是提供保险核心业务能力的核心中台，如营销、承保和理赔等业务；另一类则是支撑核心业务流程，确保保险全流程顺畅进行的通用中台，如订单、支付、客户和用户等。在此，需要特别提醒的是，遵循DDD的原则，首先要建立通用语言。在将DDD的方法引入中台设计时，我们必须先确立中台与DDD之间的通用语言。在这里，子域与中台是一致的，因此我们可以将子域统一视为中台。
中台通过事件风暴的方式可以进一步细分，最终完成业务领域的建模。中台业务领域的功能各异，限界上下文的数量和规模也会有所不同，领域模型自然也会有所区别。完成业务建模后，我们便可以运用DDD的战术设计，设计出聚合、实体、领域事件、领域服务以及应用服务等领域对象，并利用分层架构模型来完成微服务的设计。以上便是DDD、中台和微服务在应用过程中的协作模式。
在探讨了三者协作模式之后，我们继续深入探讨中台建模的过程。中台业务的抽象过程，实际上就是业务建模的过程，这与DDD的战略设计相呼应。而系统的抽象过程，则是微服务建设的过程，对应DDD的战术设计。接下来，我们将结合DDD领域建模的方法，详细阐述中台业务建模的步骤。
第一步：根据业务流程（通常适用于核心域）或功能属性、集合（通常适用于通用域或支撑域），将业务域细分为多个中台。然后，根据功能属性或重要性，将这些中台归类为核心中台或通用中台。在设计核心中台时，需要考虑企业的核心竞争力；而在设计通用中台时，则需从企业整体角度出发，考虑共享和复用的能力。
第二步：选取一个中台，根据用例、业务场景或用户旅程进行事件风暴，识别出实体、聚合和限界上下文。随后，进行领域分解，建立领域模型。由于不同中台是独立建模的，某些领域对象或功能可能会在其他领域模型中重复出现，或者本应属于同一聚合的领域对象或功能可能分散在其他中台中，这可能导致领域模型不完整或业务不内聚。不过，在这一步中，我们只需初步确定主领域模型，后续步骤会进一步提炼和重组这些领域对象。
第三步：以主领域模型为基础，扫描其他中台的领域模型，检查并确定是否存在重复或需要重组的领域对象和功能。通过提炼和重构，完善主领域模型，完成最终的领域模型设计。
第四步：选择其他主领域模型，重复第三步的过程，直到所有主领域模型都完成比对和重构。
第五步：基于最终的领域模型，完成微服务设计，实现系统的落地。
