《解构领域驱动设计》全书的脉络是按照领域驱动设计统一过程的脉络开展叙述的,核心内容就是构成领域驱动设计统一过程的三个阶段:
思维导图总结的正是这三部分内容。
全局分析阶段
我将需求分为价值需求和业务需求,它们构成了需求分析的5W模型,即:
1
价值需求对业务需求产生指导和约束作用。利益相关者分为受益的利益相关者(简称受益者)和解决问题的利益相关者(简称支持者)。系统愿景是对目标系统价值需求的精炼提取,能帮助团队就项目需要达成的目标形成共识。系统范围是目标系统问题空间的边界,可以通过识别目标系统的当前状态与未来状态明确。
2
识别业务流程时,需要注意:
按照业务目标对流程进行纵向切分,获得业务场景。根据业务场景,进一步识别业务服务。
业务服务的组成要素包括:角色、服务请求和服务价值,并将整个目标系统视为一个黑盒子。角色包括用户、策略(封装了业务规则的定时器)和伴生系统。
业务服务如果需要细化,应为其编写业务服务规约,包括:
问题空间可以被划分为多个子领域,可以根据价值之高低划分为:核心子领域、通用子领域和支撑子领域。
架构映射阶段
架构映射阶段对应于领域驱动设计解空间的战略设计阶段。
1
系统上下文用于确定解空间的边界,而在架构层面,它代表了整个目标系统,可以运用系统分层架构来表现。系统分层架构分为(自下而上):
2
限界上下文是战略层次的基本架构单元,它也是领域驱动设计最重要的模式。书中通过多方面归纳限界上下文:
限界上下文内部通过菱形对称架构来体现,菱形对称架构体现了“内外分离、南北对称”的设计思想:
作为架构的重要要素,该如何识别限界上下文?书中从业务维度、团队维度与技术维度分别加以阐述。
业务维度对限界上下文的识别顺序如下:
团队维度要求我们为限界上下文建立领域特性团队。领域特性团队的组建基于康威定律、2PTs团队与特性团队的要求。
至于技术维度,则需要根据质量属性如高并发、性能、安全等因素,要求资源隔离,从而独立定义限界上下文。
3
我将上下文映射的模式归为两类:通信协作模式和团队协作模式。
通信协作模式有四个,都是领域驱动设计本身定义的模式,菱形对称架构模式基本已经覆盖:
团队协作模式有五个,其中的发布者-订阅者模式是我个人引入的,当然,它也是业界惯用的模式了:
通过服务序列图可以确定限界上下文的上下文映射模式,并驱动出限界上下文的服务契约。
4
结合这些架构因素与模式,我总结为领域驱动架构风格。主要内容为:
领域建模阶段
领域建模阶段属于领域驱动设计的战术设计阶段,我将其分为三个环节:领域分析建模、领域设计建模和领域实现建模。
1
领域分析建模的参与人包括领域专家和开发团队,应考虑由领域专家作为整个分析建模过程的主导。建模的输入为业务服务规约,输出为领域分析模型。
我采用快速建模法获得领域分析模型。它分为五个步骤:
2
领域分析建模的输入为领域分析模型与业务服务规约的基本流程,输出则包含静态的领域设计模型(由聚合组成的类图)和动态的领域设计模型(序列图脚本或序列图)。
与领域设计模型有关的模式包括了实体、值对象、聚合、领域服务、领域事件、资源库和工厂。
实体体现了领域概念,具有ID,值对象体现了领域概念,只关注值。
聚合是边界,边界内为实体与值对象组成的对象树,根为实体,它用于维护领域概念的完整性。聚合之间只能通过聚合根实体建立关系,根实体是聚合唯一的入口和出口。
聚合作为领域建模阶段基本的设计单元,同样具有自治的特征:
领域服务主要负责:
领域事件封装了状态的变化。
工厂负责聚合从无到有的创建,资源库负责聚合生命周期的管理,包括添加、加载、变更、移除。
在获得在限界上下文限定下的领域分析模型后,需要确定各个领域模型对象的聚合边界。过程为:
服务驱动设计分为两个步骤:分解任务和分配职责。它的基础则是角色构造型,结合菱形对称架构,一个限界上下文的角色构造型包括:远程服务、本地服务(应用服务)、领域服务、聚合和端口。
分解的任务会形成一棵任务树,业务服务为任务树的根,组合任务为枝,原子任务为叶。过程为:
分配职责是一个固定的流程,将各个任务分配给角色构造型:
服务驱动设计最终输出的是动态的序列图脚本,驱动出了领域模型对象的方法,明确了领域对象之间的协作方式。
3
领域实现建模的输入是领域设计模型,以及业务服务规约的验收标准;输出为领域实现模型,包括了领域层的产品代码和测试代码。
领域实现建模推荐采用测试驱动开发。对于限界上下文而言,菱形对称架构与测试金字塔存在一定的对应关系。聚合不依赖任何外部资源,非常易于编写单元测试。领域服务的单元测试可以通过模拟端口来编写。应用服务编写集成测试。远程服务编写契约测试。
服务驱动设计与测试驱动开发可以很好的结合起来。服务驱动设计的方向是由外向内,测试驱动开发的方向是由内向外,服务驱动设计输出的序列图脚本可以作为测试驱动开发的输入。
测试驱动开发遵循Kent Beck提出的简单设计原则:
测试驱动开发还要遵循Robert Martin提出的三定律:
测试驱动开发对于领域驱动设计虽非必要,但它有助于提升领域实现模型的质量。