领域驱动整体流程
1.自下而上
DDD自下而上的领域建模通常采用事件风暴,通过头脑风暴列出所有可能的业务行为和事件,然后找出产生这些行为的领域对象。通过事件风暴来梳理业务和抽象,在事件风暴中根据一些业务操作和行为找出实体或值对象,进而将业务关联紧密的实体和值对象进行组合,构成聚合。再根据业务语义将多个聚合划定在同一个限界上下文内,并在限界上下文内完成领域建模。同时通过事件风暴确认哪些实体在边界内,哪些实体在边界外。自下而上模式适用于遗留系统业务模型的演进式重构。
事件风暴是建立领域模型的主要方法,事件风暴过程是从发散到收敛的过程。事件风暴通常通过用例与场景分析,尽可能全面无遗漏地分解业务领域,并梳理领域对象之间的关系,这是发散的过程。在事件风暴过程中会产生很多实体、命令、事件等领域对象,将这些领域对象从不同的维度进行聚类,形成如聚合、限界上下文等边界,建立领域模型,这是收敛的过程。事件风暴大致可以分为以下几个步骤。(参考其它内容)
① 业务抽象。在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等。在业务抽象过程中,需要识别领域事件、决策命令、领域名词。
② 统一语言。根据业务抽象梳理出领域概念元素。
③ 概念建模。根据领域概念元素,将业务紧密相关的实体进行组合形成聚合,同时确定聚合中的聚合根、值对象和实体。聚合之间的边界通常是逻辑边界。
④ 问题领域划分。根据业务及语义边界等因素,将一个或者多个聚合划定在一个限界上下文内,形成领域模型。限界上下文之间的边界是第二层边界,这一层边界可能就是未来微服务划分的边界,不同限界上下文内的领域逻辑被物理隔离在不同的微服务中运行。
⑤ 业务服务识别及细化。业务服务具有业务价值,并且可以以 API 形式对外提供接口供消费者使用。根据具体的业务需求来划分业务服务,每个业务服务都可以由多个聚合实现。基于已经识别出的业务服务,继续细化聚合,从而识别 API,确定每个业务服务对外的粒度更细的具体接口能力。
⑥ 接口实现。对定义好的接口进行恰当的实现。
2.自上而下
先做顶层设计,从最高领域开始逐级分解为子领域,比如根据业务属性分为核心子领域(或核心领域)、通用子领域(或通用领域)、支撑子领域(或支撑领域)。在每个子领域中确定领域模型,分别为每个领域模型定义限界上下文,在开发阶段限界上下文就可以被直接转化为微服务。自上而下模式适用于全新的应用建设,或者将旧系统推倒重建的情况。由于自上而下模式不必受限于现有应用,因此可以直接使用 DDD 领域逐级分解的领域建模方法。
自上而下模式的主要步骤具体如下:
① 问题领域划分。将领域分解为子领域,子领域又可以分为核心领域、通用领域和支撑领域。
② 概念建模。对子领域建模,划分领域边界,建立领域模型和限界上下文,同“自下而上”模式。
③ 业务服务识别及细化。根据限界上下文进行业务服务的设计及细化,同“自下而上”模式。