「尺有所短，寸有所长；不忘初心，方得始终。」
一、中台、微服务与DDD的本质
中台的本质：提炼各个业务板块的共同需求，进行业务和系统抽象，形成通用的业务模型。 微服务的本质：「是可以独立的部署、运行、升级，承载某一个维度的业务的基础架构。」 DDD的本质：通过统一语言、业务抽象、领域划分和领域建模等一系列手段来控制软件复杂度的方法论。
「中台是抽象出来的业务模型，微服务是业务模型的系统实现，DDD 作为方法论可以同时指导中台业务建模和微服务建设，三者相辅相成。」
二、DDD、中台和微服务的协作
DDD、中台以及微服务虽然属于不同层面的东西，但可以将它们进行分解对照，以此理解它们之间的关系：
在将企业级业务作为一个领域进行领域细分时，也可以从不同视角来划分：
「DDD 视角」
整个业务的问题域可以划分为不同的子域，「子域又可分为核心域、通用域和支撑域。」
「中台视角」
「业务域细分后的业务中台，可分为核心中台和通用中台」。通用中台对应 DDD 的通用域和支撑域，核心中台对应 DDD 的核心域。
「微服务视角」
「领域模型所在的限界上下文对应微服务」，一个微服务由一个或多个限界上下文组成。
三、中台业务建模怎么实现
通过DDD建设中台总的来说沉淀为两步：
「战略设计」：业务抽象实现中台业务建模的过程 「战术设计」：系统抽象搭建微服务的建设过程
而在「具体实施过程」中可以分为五步：
「第一步」
根据问题域的业务划分中台，并以企业能力规划确定核心中台或通用中台。「核心中台要考虑企业核心竞争力，通用中台要考虑企业级的共享和复用能力。」
「第二步」
「根据中台所在的业务领域，运用事件风暴，确定实体、聚合和限界上下文，建立领域模型。」
「第三步」
将【「当前」】领域（中台）作为主领域模型，并以此为基础，针对不同领域的中台，将重复或需要重组的领域对象、功能，提炼至主领域模型，使得主领域模型更加丰满，达到「高内聚」的设计思想，完成领域模型设计。
「第四步」
将【「其他」】领域（中台）作为主领域模型，重复第三步，直至所有领域模型完成领域对象、功能的提炼，完善领域模型的建设。
「第五步」
将完善后的各个领域模型作为微服务设计的基础，完成微服务的拆分和设计，完成微服务落地
四、案例
根据以上的流程下来，中台的基本map就可以建设出来，以我所在的保险行业为案例作为分析对象，保险域是一个大域，属于企业级。「按照DDD的战略设计，可以将保险域划分为【承保，核保，客户，用户，产品】等几个子域」，而在保险企业中，
【承保，核保】关乎企业受益，显然是核心业务，属于核心域。 【客户，用户，产品】作为核心域的支撑，并具有企业级的单一特性，属于通用域。
基于此，我们可以画出保险域的中台建设基本的架构图，并「以此按照DDD的战术设计落地保险域的中台建设与微服务落地」：
