领域驱动整体流程

1.自下而上

DDD自下而上的领域建模通常采用事件风暴，通过头脑风暴列出所有可能的业务行为和事件，然后找出产生这些行为的领域对象。通过事件风暴来梳理业务和抽象，在事件风暴中根据一些业务操作和行为找出实体或值对象，进而将业务关联紧密的实体和值对象进行组合，构成聚合。再根据业务语义将多个聚合划定在同一个限界上下文内，并在限界上下文内完成领域建模。同时通过事件风暴确认哪些实体在边界内，哪些实体在边界外。自下而上模式适用于遗留系统业务模型的演进式重构。

事件风暴是建立领域模型的主要方法，事件风暴过程是从发散到收敛的过程。事件风暴通常通过用例与场景分析，尽可能全面无遗漏地分解业务领域，并梳理领域对象之间的关系，这是发散的过程。在事件风暴过程中会产生很多实体、命令、事件等领域对象，将这些领域对象从不同的维度进行聚类，形成如聚合、限界上下文等边界，建立领域模型，这是收敛的过程。事件风暴大致可以分为以下几个步骤。(参考其它内容)

① 业务抽象。在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等。在业务抽象过程中，需要识别领域事件、决策命令、领域名词。

② 统一语言。根据业务抽象梳理出领域概念元素。

③ 概念建模。根据领域概念元素，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。聚合之间的边界通常是逻辑边界。

④ 问题领域划分。根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务划分的边界，不同限界上下文内的领域逻辑被物理隔离在不同的微服务中运行。

⑤ 业务服务识别及细化。业务服务具有业务价值，并且可以以 API 形式对外提供接口供消费者使用。根据具体的业务需求来划分业务服务，每个业务服务都可以由多个聚合实现。基于已经识别出的业务服务，继续细化聚合，从而识别 API，确定每个业务服务对外的粒度更细的具体接口能力。

⑥ 接口实现。对定义好的接口进行恰当的实现。

2.自上而下

先做顶层设计，从最高领域开始逐级分解为子领域，比如根据业务属性分为核心子领域（或核心领域）、通用子领域（或通用领域）、支撑子领域（或支撑领域）。在每个子领域中确定领域模型，分别为每个领域模型定义限界上下文，在开发阶段限界上下文就可以被直接转化为微服务。自上而下模式适用于全新的应用建设，或者将旧系统推倒重建的情况。由于自上而下模式不必受限于现有应用，因此可以直接使用 DDD 领域逐级分解的领域建模方法。

自上而下模式的主要步骤具体如下：

① 问题领域划分。将领域分解为子领域，子领域又可以分为核心领域、通用领域和支撑领域。

② 概念建模。对子领域建模，划分领域边界，建立领域模型和限界上下文，同“自下而上”模式。

③ 业务服务识别及细化。根据限界上下文进行业务服务的设计及细化，同“自下而上”模式。