支付宝打赏 
微信打赏 
实战案例
为什么需要DDD
复杂系统设计：
- 系统多，业务逻辑复杂，概念不清晰，需要合适的方法帮助我们理清楚边界，逻辑和概念。
多团队协同：
- 边界不清晰，系统依赖复杂，语言不统一导致沟通和理解困难。
- 需要一种方式把业务和技术概念统一，大家用一种语言沟通。
设计与实现一致性：
- PRD，详细设计和代码实现天差万别，需要一种方法可以把业务需求快速转换为设计，同时还要保持设计与代码的一致性。
架构统一，可复用资产和扩展性：
- 当前取决于开发的同学具备很好的抽象能力和高编程的技能，需要好的方法指导我们做抽象和实现。
DDD的价值
边界清晰的设计方法：
- 通过领域划分，识别哪些需求应该在哪些领域，不断拉齐团队对需求的认知，分而治之，控制规模。
统一语言：
- 团队在有边界的上下文中有意识地形成对事物进行统一的描述，形成统一的概念(模型)。
业务领域的知识沉淀：
- 通过反复论证和提炼模型，使得模型必须与业务的真实世界保持一致，促使知识(模型)可以很好地传递和维护。
面向业务建模：
- 领域模型与数据模型分离，业务复杂度和技术复杂度分离。
为什么DDD适合微服务？
微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方
DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。
DDD 不是架构，而是一种架构设计方法论，通过边界划分将复杂业务领域简单化，设计出清晰的领域和应用边界。
DDD与微服务的关系
DDD：
- 从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。
微服务：
- 运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。
如何划分领域模型和微服务的边界
第一步：
- 在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。
第二步：
- 根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。
第三步：
- 根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。
- 不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离。
DDD领域的领域建模方法
第一步:
- 将领域分解为子域，子域可以分为核心域、通用域和支撑域；
第二步:
- 对子域建模，划分领域边界，建立领域模型和限界上下文；
第三步:
- 根据限界上下文进行微服务设计。
如何用事件风暴构建领域模型？
领域建模的过程主要包括产品愿景、业务场景分析、领域建模和微服务拆分与设计这几个重要阶段。
产品愿景：
- 对产品顶层价值的设计，使产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。
业务场景分析：
- 从用户视角出发的，根据业务流程或用户旅程，采用用例和场景分析，探索领域中的典型场景，找出领域事件、实体和命令等领域对象，支撑领域建模。
- 事件风暴参与者要尽可能地遍历所有业务细节，充分发表意见，不要遗漏业务要点。
领域建模：
- 领域建模时，会根据场景分析过程中产生的领域对象，比如命令、事件等之间关系，找出产生命令的实体，分析实体之间的依赖关系组成聚合，为聚合划定限界上下文，建立领域模型以及模型之间的依赖。
- 领域模型利用限界上下文向上可以指导微服务设计，通过聚合向下可以指导聚合根、实体和值对象的设计。
微服务拆分与设计：
- 原则上一个领域模型就可以设计为一个微服务。
基本概念
领域和子域
领域是用来确定范围的，范围即边界，领域就是这个边界内要解决的业务问题域。
子领域：领域可以进一步划分为子领域，把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。
核心域、通用域和支撑域
核心域：
- 决定产品和公司核心竞争力的子域，它是业务成功的主要因素和公司的核心竞争力。
通用域：
- 没有太多个性化的诉求，同时被多个子域使用的通用功能子域，比如认证、权限等。
支撑域：
- 既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，例如数据代码类的数据字典等系统。
注意：商业模式的不同会导致核心域划分结果的不同。
通用语言
在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。
通用语言是团队统一的语言，不管你在团队中承担什么角色，在同一个领域的软件生命周期里都使用统一的语言进行交流。
实体
实体的业务形态：
领域模型中的实体是多个属性、操作或行为的载体。
在事件风暴中，我们可以根据命令、操作或者事件，找出产生这些行为的业务实体对象，进而按照一定的业务规则将依存度高和业务关联紧密的多个实体对象和值对象进行聚类，形成聚合。
- 实体和值对象是组成领域模型的基础单元。
实体的代码形态：
在代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务逻辑。
在 DDD 里，这些实体类通常采用充血模型，与这个实体相关的所有业务逻辑都在实体类的方法中实现，跨多个实体的领域逻辑则在领域服务中实现。
实体的运行形态：
实体以 DO（领域对象）的形式存在，每个实体对象都有唯一的 ID。
可以对一个实体对象进行多次修改，修改后的数据和原来的数据可能会大不相同。
由于它们拥有相同的 ID，它们依然是同一个实体。
- 比如商品是商品上下文的一个实体，通过唯一的商品 ID 来标识，不管这个商品的数据如何变化，商品的 ID 一直保持不变，它始终是同一个商品。
实体的数据库形态：
与传统数据模型设计优先不同，DDD 是先构建领域模型，针对实际业务场景构建实体对象和行为，再将实体对象映射到数据持久化对象。
在领域模型映射到数据模型时，一个实体可能对应 0 个、1 个或者多个数据库持久化对象。
大多数情况下实体与持久化对象是一对一。
在某些场景中，有些实体只是暂驻静态内存的一个运行态实体，它不需要持久化。
- 比如，基于多个价格配置数据计算后生成的折扣实体。
而在有些复杂场景下，实体与持久化对象则可能是一对多或者多对一的关系。
- 比如，用户 user 与角色 role 两个持久化对象可生成权限实体，一个实体对应两个持久化对象，这是一对多的场景。
值对象
值对象描述了领域中的一件东西，这个东西是不可变的，它将不同的相关属性组合成了一个概念整体。
值对象的业务形态:
值对象只是若干个属性的集合，只有数据初始化操作和有限的不涉及修改数据的行为，基本不包含业务逻辑。
- 值对象的属性集虽然在物理上独立出来了，但在逻辑上它仍然是实体属性的一部分，用于描述实体的特征。
值对象的代码形态:
如果值对象是单一属性，则直接定义为实体类的属性。
如果值对象是属性集合，则把它设计为 Class 类，Class 将具有整体概念的多个属性归集到属性集合，这样的值对象没有 ID，会被实体整体引用。
值对象的运行形态：
值对象嵌入到实体的话，有这样两种不同的数据格式，也可以说是两种方式，分别是属性嵌入的方式和序列化大对象的方式。
引用单一属性的值对象或只有一条记录的多属性值对象的实体，可以采用属性嵌入的方式嵌入。
引用一条或多条记录的多属性值对象的实体，可以采用序列化大对象的方式嵌入。
- 比如，人员实体可以有多个通讯地址，多个地址序列化后可以嵌入人员的地址属性。
值对象创建后就不允许修改了，只能用另外一个值对象来整体替换。
值对象的数据库形态:
在领域建模时，可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量。
在数据建模时，可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。
实体和值对象的关系：
同样的对象在不同的场景下，可能会设计出不同的结果。
有些场景中，地址会被某一实体引用，它只承担描述实体的作用，并且它的值只能整体替换，这时候就可以将地址设计为值对象。
- 比如收货地址。
在某些业务场景中，地址会被经常修改，地址是作为一个独立对象存在的，这时候它应该设计为实体。
- 比如行政区划中的地址信息维护。
限界上下文
通用语言定义上下文含义，限界上下文则定义领域边界，以确保每个上下文含义在它特定的边界内都具有唯一的含义。
限界上下文用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。
这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。
领域边界就是通过限界上下文来定义的
限界上下文和微服务的关系：
理论上限界上下文就是微服务的边界，限界上下文内的领域模型映射到微服务。
- 限界上下文是微服务设计和拆分的主要依据。
在领域模型中，如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。
聚合
领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合。
- 它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。
聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，是数据修改和持久化的基本单元。
- 每一个聚合对应一个仓储，实现数据的持久化。
聚合内实体以充血模型实现个体业务能力，以及业务逻辑的高内聚。
跨多个实体的业务逻辑通过领域服务来实现，
跨多个聚合的业务逻辑通过应用服务来实现。
比如有的业务场景需要同一个聚合的 A 和 B 两个实体来共同完成，就可以将这段业务逻辑用领域服务来实现。
- 有的业务逻辑需要聚合 C 和聚合 D 中的两个服务共同完成，就可以用应用服务来组合这两个服务。
怎样设计聚合？
DDD领域建模通常采用事件风暴，它通常采用用例分析、场景分析和用户旅程分析等方法。
通过头脑风暴列出所有可能的业务行为和事件，然后找出产生这些行为的领域对象，并梳理领域对象之间的关系。
- 找出聚合根，找出与聚合根业务紧密关联的实体和值对象，再将聚合根、实体和值对象组合，构建聚合。
聚合的一些设计原则:
在一致性边界内建模真正的不变条件：
- 聚合用来封装真正的不变性，而不是简单地将对象组合在一起。
- 聚合内有一套不变的业务规则，各实体和值对象按照统一的业务规则运行，实现对象数据的一致性。
- 边界之外的任何东西都与该聚合无关。
设计小聚合：
如果聚合设计得过大，聚合会因为包含过多的实体，导致实体之间的管理过于复杂。
- 高频操作时会出现并发冲突或者数据库锁，最终导致系统可用性变差。
小聚合设计则可以降低由于业务过大导致聚合重构的可能性，让领域模型更能适应业务的变化。
通过唯一标识引用其它聚合：
- 聚合之间是通过关联外部聚合根 ID 的方式引用，而不是直接对象引用的方式。
- 外部聚合的对象放在聚合边界内管理，容易导致聚合的边界不清晰，也会增加聚合之间的耦合度。
在边界之外使用最终一致性：
- 聚合内数据强一致性，而聚合之间数据最终一致性。
- 在一次事务中，最多只能更改一个聚合的状态。
- 如果一次业务操作涉及多个聚合状态的更改，应采用领域事件的方式异步修改相关的聚合，实现聚合之间的解耦。
通过应用层实现跨聚合的服务调用：
- 为实现微服务内聚合之间的解耦，以及未来以聚合为单位的微服务组合和拆分。
- 应避免跨聚合的领域服务调用和跨聚合的数据库表关联。
聚合根
如果把聚合比作组织，那聚合根就是这个组织的负责人。
- 聚合根也称为根实体，它不仅是实体，还是聚合的管理者。
首先它作为实体本身，拥有实体的属性和业务行为，实现自身的业务逻辑。
其次它作为聚合的管理者，在聚合内部负责协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑。
最后在聚合之间，它还是聚合对外的接口人，以聚合根 ID 关联的方式接受外部任务和请求。
- 在上下文内实现聚合之间的业务协同。
也就是说，聚合之间通过聚合根 ID 关联引用。
- 如果需要访问其它聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内实体。
领域事件
在事件风暴（Event Storming）时，除了命令和操作等业务行为以外，还有一种非常重要的事件，这种事件发生后通常会导致进一步的业务操作，在 DDD 中这种事件被称为领域事件。
一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。
领域事件总体架构
领域事件的执行需要一系列的组件和技术来支撑。
- 领域事件处理包括：事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等。
基本架构
DDD分层架构
DDD 的分层架构最早是传统的四层架构。
后来四层架构有了进一步的优化，实现了各层对基础层的解耦。
再后来领域层和应用层之间增加了上下文环境（Context）层，五层架构（DCI）就此形成了。
在最早的传统四层架构中，基础层是被其它层依赖的，它位于最核心的位置，那按照分层架构的思想，它应该就是核心，但实际上领域层才是软件的核心，所以这种依赖是有问题的。
后来采用了依赖倒置（Dependency inversion principle,DIP）的设计，优化了传统的四层架构，实现了各层对基础层的解耦。
用户接口层:
用户接口层负责向用户显示信息和解释用户指令。
应用层:
它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。
应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。
- 应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
领域层:
领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。
领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。
基础层:
它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。
- 比较常见的功能是提供数据库持久化。
DDD分层架构最重要的原则是什么？
每层只能与位于其下方的层发生耦合。
架构根据耦合的紧密程度分为两种：
- 严格分层架构和松散分层架构。
优化后的 DDD 分层架构模型就属于严格分层架构，任何层只能对位于其直接下方的层产生依赖。
而传统的 DDD 分层架构则属于松散分层架构，它允许某层与其任意下方的层发生依赖。
在严格分层架构中：
- 领域服务只能被应用服务调用，而应用服务只能被用户接口层调用，服务是逐层对外封装或组合的，依赖关系清晰。
在松散分层架构中：
- 领域服务可以同时被应用层或用户接口层调用，服务的依赖关系比较复杂且难管理，甚至容易使核心业务逻辑外泄。
微服务架构模型
整洁架构(洋葱架构)：
在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。
整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。
外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。
在洋葱架构中，各层的职能是这样划分的：
- 领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则。
- 领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。
- 领域服务实现涉及多个实体的复杂业务逻辑。
- 应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例。
- 最外层主要提供适配的能力，适配能力分为主动适配和被动适配。
- 主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。
- 被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
- 红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
六边形架构：
六边形架构的核心理念是：应用是通过端口与外部进行交互的。
六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。
它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。
六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。
六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分如下：
- 红圈内的六边形实现应用的核心业务逻辑。
- 外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。
六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。
- 这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。
项目级微服务
项目级微服务的内部遵循分层架构模型就可以了。
领域模型的核心逻辑在领域层实现，服务的组合和编排在应用层实现，通过 API 网关为前台应用提供服务，实现前后端分离。
但项目级的微服务可能会调用其它微服务，比如某个项目级微服务 B 调用认证微服务 A，完成登录和权限认证。
通常项目级微服务之间的集成，发生在微服务的应用层，由应用服务调用其它微服务发布在 API 网关上的应用服务。
图中微服务 B 中红色框内的应用服务 B，它除了可以组合和编排自己的领域服务外，还可以组合和编排外部微服务的应用服务。
它只要将编排后的服务发布到 API 网关供前端调用，这样前端就可以直接访问自己的微服务了。
代码模型
服务的封装与组合
基础层:
- 基础层的服务形态主要是仓储服务。
- 仓储服务包括接口和实现两部分。
- 仓储接口服务供应用层或者领域层服务调用，仓储实现服务，完成领域对象的持久化或数据初始化。
领域层:
- 领域层实现核心业务逻辑，负责表达领域模型业务概念、业务状态和业务规则。
- 主要的服务形态有实体方法和领域服务。
- 实体采用充血模型，在实体类内部实现实体相关的所有业务逻辑，实现的形式是实体类中的方法。
- DDD提倡富领域模型，尽量将业务逻辑归属到实体对象上，实在无法归属的部分则设计成领域服务。
- 领域服务会对多个实体或实体方法进行组装和编排，实现跨多个实体的复杂核心业务逻辑。
应用层:
应用层用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，负责不同聚合之间的服务和数据协调，负责微服务之间的事件发布和订阅。
应用服务内用于组合和编排的服务，主要来源于领域服务，也可以是外部微服务的应用服务。
除了完成服务的组合和编排外，应用服务内还可以完成安全认证、权限校验、初步的数据校验和分布式事务控制等功能。
为了实现微服务内聚合之间的解耦，聚合之间的服务调用和数据交互应通过应用服务来完成。
原则上我们应该禁止聚合之间的领域服务直接调用和聚合之间的数据表关联。
用户接口层:
用户接口层是前端应用和微服务之间服务访问和数据交换的桥梁。
它处理前端发送的 Restful 请求和解析用户输入的配置文件等，将数据传递给应用层。
获取应用服务的数据后，进行数据组装，向前端提供数据服务。
Facade 服务分为接口和实现两个部分。
完成服务定向，DO 与 DTO 数据的转换和组装，实现前端与应用层数据的转换和交换。
数据对象视图
数据持久化对象 PO(Persistent Object):
- 与数据库结构映射，是数据持久化过程中的数据载体。
领域对象 DO（Domain Object）:
- 微服务运行时的实体，是核心业务的载体。
数据传输对象 DTO（Data Transfer Object）:
- 用于前端与应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体。
视图对象 VO（View Object）:
- 用于封装展示层指定页面或组件的数据。
基础层:
- 基础层的主要对象是 PO 对象。
- 当 DO 数据需要持久化时，仓储服务会将 DO 转换为 PO 对象，完成数据库持久化操作。
- 当 DO 数据需要初始化时，仓储服务从数据库获取数据形成 PO 对象，并将 PO 转换为 DO，完成数据初始化。
领域层:
- 领域层的主要对象是 DO 对象。
- DO 是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑。
- 通过 DO 和 PO 转换，可以完成数据持久化和初始化。
应用层:
- 应用层的主要对象是 DO 对象。
- 如果需要调用其它微服务的应用服务，DO 会转换为 DTO，完成跨微服务的数据组装和传输。
- 用户接口层先完成 DTO 到 DO 的转换，然后应用服务接收 DO 进行业务处理。
- 如果 DTO 与 DO 是一对多的关系，这时就需要进行 DO 数据重组。
用户接口层:
- 完成 DO 和 DTO 的互转，完成微服务与前端应用数据交互及转换。
- Facade 服务会对多个 DO 对象进行组装，转换为 DTO 对象，向前端应用完成数据转换和传输。
前端应用:
- 前端应用主要是 VO 对象。
- 展现层使用 VO 进行界面展示，通过用户接口层与应用层采用 DTO 对象进行数据交互。
防腐层
防腐层（Anti-Corruption Layer）思想：
- 通过引入一个间接的层，可以有效隔离限界上下文之间的耦合。
- 防腐层往往属于下游限界上下文，用以隔绝上游限界上下文可能发生的变化。
即使上游发生了变化，影响的也仅仅是防腐层中的单一变化，只要防腐层的接口不变，下游限界上下文的其他实现就不会受到影响。
- 比如用户订单微服务本地增加一个订单支付Service的Feign接口。
- 这样用户订单Service就像本地调用一样调用支付Service，再通过这个Feign接口实现远程调用，这样的设计叫做防腐层设计。
缺点是代码会重复，但解耦彻底。
、
充血模型和贫血模型：
贫血模型：
实体不带有任何行为方法，也不带有聚合关联关系，作用基本相当于值对象（ValueObject），仅作为值传递的对象，和传统三层项目架构中的实体具有相同作用，不建议使用。
- 一般使用的DTO就可以被当做是值对象。
充血模型：
实体中带有具有行为方法和聚合关联关系，行为方法是说
create、save、delete等封装了一类可以指代行为的方法，比如在用户实体对象中具有用户组实体的引用，这样当我们需要操作用户组时，只通过用户实体进行操作就可以。工程实践中，建议采用充血模型，好处是隐藏胶水代码，提升代码可读性，使关注点聚焦于业务实现。
中台
中台体现的是一种企业级的能力，它提供的是一套企业级的整体解决方案，解决小到企业、集团，大到生态圈的能力共享、联通和融合问题，支持业务和商业模式创新。
中台是企业级能力复用平台
企业级中台微服务
企业级中台微服务的集成不能像项目级微服务一样，在某一个微服务内完成跨微服务的服务组合和编排。
可以在中台微服务之上增加一层，增加的这一层就位于红色框内，它的主要职能就是处理跨中台微服务的服务组合和编排，以及微服务之间的协调，它还可以完成前端不同渠道应用的适配。
如果再将它的业务范围扩大一些，我可以将它做成一个面向不同行业和渠道的服务平台。
借助BFF服务，但BFF 微服务与其它微服务存在较大的差异，就是它没有领域模型，因此这个微服务内也不会有领域层。
BFF 微服务可以承担应用层和用户接口层的主要职能，完成各个中台微服务的服务组合和编排，可以适配不同前端和渠道的要求。
DDD、中台和微服务的协作模式
企业内的所有业务就是一个领域。
在进行领域细分时，从 DDD 视角来看，子域可分为核心域、通用域和支撑域。
从中台建设的视角来看，业务域细分后的业务中台，可分为核心中台和通用中台。
中台如何建模？
第一步：
- 按照业务流程（通常适用于核心域）或者功能属性、集合（通常适用于通用域或支撑域），将业务域细分为多个中台，再根据功能属性或重要性归类到核心中台或通用中台。
第二步：
- 选取中台，根据用例、业务场景或用户旅程完成事件风暴，找出实体、聚合和限界上下文。
- 依次进行领域分解，建立领域模型。
第三步：
- 以主领域模型为基础，扫描其它中台领域模型，检查并确定是否存在重复或者需要重组的领域对象、功能，提炼并重构主领域模型，完成最终的领域模型设计。
第四步：
- 选择其它主领域模型重复第三步，直到所有主领域模型完成比对和重构。
第五步：
- 基于领域模型完成微服务设计，完成系统落地。
