如何在推行DDD时不照本宣科地使用《领域驱动设计》一书（下）

2．架构映射阶段

架构映射（architectural mapping）阶段根据全局分析阶段获得的产出物，即价值需求与业务需求，分别从组织级、业务级与系统级3个层次完成对问题空间的求解，映射为架构层面的解决方案。整个架构映射阶段与主要工作流的关系如图3-3所示。

通过全局分析阶段完成对问题空间的探索后，对解空间架构层面的解决方案映射，几乎可以做到顺势而为。通过执行组织级映射、业务级映射与系统级映射这3个过程工作流，分别获得组织级架构、业务级架构与系统级架构。

在执行组织级映射时，设计者站在整个组织的高度，在全局分析阶段输出的价值需求的指导下，通过系统上下文呈现利益相关者、目标系统与伴生系统之间的关系。系统上下文实际上确定了解空间的边界，除了系统边界与外部环境之间必要的集成，整个开发团队都工作在系统上下文的边界之内。

一旦确定了系统上下文，就可以根据全局分析阶段输出的业务需求执行业务级映射。根据语义相关性和功能相关性对业务服务表达出来的业务知识进行归类与归纳，即可识别出边界相对合理的限界上下文。限界上下文的内部架构遵循菱形对称架构模式，充分体现它作为自治的架构单元、领域模型的知识语境，提供独立完整的业务能力；限界上下文之间则通过不同的上下文映射模式表达上游和下游之间的协作方式，规范服务契约。

系统级映射建立在限界上下文之上，在全局分析阶段划分的子领域的指导下，在系统上下文的边界内部建立系统分层架构。该分层架构将属于核心子领域的限界上下文映射为业务价值层，将支撑子领域和通用子领域的限界上下文映射为基础层，并从前端用户体验的角度考虑引入边缘层，为前端提供一个统一的网关入口，并通过聚合服务的方式响应前端发来的客户端请求。

架构映射阶段的里程碑目标是完成从问题空间到解空间的架构映射，通过组织级映射、业务级映射和系统级映射获得遵循领域驱动架构风格的架构映射战略设计方案（参见附录D）。

架构映射阶段就是目标系统的架构战略设计。解决方案的获得建立在全局分析结果的基础之上，不同层次的映射方法引入了不同的领域驱动设计元模型，建立的领域驱动架构风格发挥了这些设计元模型的价值，保证了目标系统架构的一致性，以限界上下文为核心的业务级架构与系统级架构也成了响应业务变化的关键。

参与架构映射阶段的角色包括业务分析师、产品经理、用户体验设计师、项目经理、架构师、技术负责人、开发人员。其中，业务分析师和产品经理共同扮演领域专家的角色。由于架构映射阶段属于解空间的范畴，邀请客户参与本阶段的战略设计活动，可能会适得其反。若有必要，在执行组织级映射获得系统上下文的过程中，可以咨询和参考客户的意见。在本阶段，架构师（尤其是业务架构师与应用架构师）应成为关键的引导者和推动者。

3．领域建模阶段

领域建模阶段是对问题空间战术层次的求解过程，它的目标是建立领域模型。领域建模必须在领域驱动架构风格的约束下，在限界上下文的边界内进行。这样一方面用分而治之的思想降低了领域建模的难度，另一方面也体现了领域建模依据的统一语言存在限定的语境，这也是模型驱动设计区别于其他建模过程的根本特征。根据领域模型表现特征的不同，领域建模可分为领域分析建模、领域设计建模和领域实现建模，对应于本阶段的3个主要过程工作流。整个领域建模阶段与主要工作流的关系如图3-4所示。

领域建模是一个统一而连续的过程。执行领域分析建模时，以领域专家为主导，整个领域特性团队共同针对限界上下文对应的领域开展分析建模，即在统一语言的指导下对业务服务进行提炼与抽象，获得的领域概念形成领域分析模型；执行领域设计建模时，以开发团队为主导，围绕每个完整的业务服务开展设计工作，获得领域设计模型；领域实现建模仍然由开发团队主导，在拆分业务服务为任务的基础上开展测试驱动开发，编写出领域相关的产品代码和单元测试代码，形成领域实现模型。

领域分析模型、领域设计模型和领域实现模型共同组成了领域模型。在执行主要的过程工作流时，还需要注意领域分析模型、领域设计模型和领域实现模型之间的同步，保证领域模型的统一。

推动领域建模完成从问题空间到解空间战术求解的核心驱动力是“领域”，在领域驱动设计统一过程中，就是通过业务服务表达领域知识，成为领域分析建模、领域设计建模和领域分析建模的驱动力。

领域建模阶段的里程碑目标是完成从问题空间到解空间的模型构建，通过领域分析建模、领域设计建模和领域实现建模逐步获得领域模型。领域模型包括如下内容。

q领域分析模型：业务服务规约和领域模型概念图。

q领域设计模型：以聚合为核心的静态设计类图和由角色构造型组成的动态序列图与序列图脚本。

q领域实现模型：实现业务功能的产品代码和验证业务功能的测试代码。

参与领域建模阶段的角色主要为领域特性团队业务分析师、开发人员和测试人员，其中业务分析师负责细化业务服务，测试人员为业务服务编写验收标准，开发人员进行服务驱动设计和测试驱动开发，共同完成领域建模。

3.2.3　统一过程的静态结构

领域驱动设计统一过程通过纵轴展现了工作流（work flow），包括过程工作流与支撑工作流。其中，在执行过程工作流时，还需要应用领域驱动设计元模型中的模式（pattern）或丰富到领域驱动设计体系中的方法（method）。

1．过程工作流

在讲解领域驱动设计统一过程的各个阶段时，我已阐述了这些阶段与各个过程工作流之间的关系，图3-1也通过工作流图示的面积大小体现了这种关系。这一对应关系主要体现了各个阶段执行活动的主次之分，过程工作流的执行效果会直接影响阶段的里程碑与产出物。

统一过程的所有过程工作流都运用了领域驱动设计的设计元模型。正是通过这种方式将相对零散的设计元模型糅合到一个完整的设计过程中，为开发团队运用领域驱动设计提供过程指导。为了更好地使领域驱动设计落地，我在沿用设计元模型的基础上，丰富了领域驱动设计体系，增加了一些新的方法，这些方法也可以认为是设计元模型的一部分。过程工作流与其运用的设计元模型之间的关系如表3-1所示。

表3-1　过程工作流与设计元模型

 

无论模式还是方法，都有知识零散之虞，它们就像一颗颗晶莹剔透的珍珠，在实践落地时常常会有遗珠之憾，因此需要用领域驱动设计统一过程这条线把它们串联起来，打造成一件完整的珠宝首饰，如此才能发出整体的耀眼光芒。

2．支撑工作流

虽说领域驱动设计是以“领域”为核心关注点的软件构建过程，但它仍然属于软件构建的技术范畴；而我们在软件构建工作中面对的太多问题，实际属于管理学的范畴。《人件》认为：“开发的本质迥异于生产；然而，开发管理者的思想却通常被生产环境衍生而来的管理哲学所左右。”^[13]同理，当我们改变了软件构建的过程时，如果还在沿用过去那一套管理软件构建的方法，就会出现“水土不服”的现象。因此，领域驱动设计统一过程需要对项目管理流程、需求管理体系和团队管理制度做出相应的调整，这些共同组成了统一过程的支撑工作流。

关于项目管理，Eric Evans早在十余年前就提到了敏捷开发过程与领域驱动设计之间的关系，他提出了两个开发实践^[8]3：

q迭代开发；

q开发人员与领域专家具有密切的关系。

领域驱动设计统一过程并未对项目管理流程做出硬性的规定，然而迭代开发因为其增量开发、小步前行、快速反馈、响应变化等优势，能够非常好地与领域驱动设计相结合，可考虑将其引入领域建模阶段，形成分析、设计和实现的迭代建模与开发流程。全局分析阶段与架构映射阶段也可采用迭代模式，但它们在管理流程上更像RUP的先启阶段。短暂快速的先启阶段与迭代建模的增量开发相结合，形成一种“最小计划式设计”。它是软件开发过程的中庸之道，既避免了瀑布型的计划式设计因为庞大的问题空间形成分析瘫痪（analysisparalysis），又不至于走向无设计的另一个极端。

领域驱动设计的成败很大程度上取决于需求的质量。全局分析阶段的主要目标就是对问题空间进行价值需求分析与业务需求分析；在领域建模阶段，也需要领域特性团队的业务分析师针对全局分析获得的业务服务进行深入分析。这些都是领域驱动设计统一过程对需求管理流程的要求。

与需求管理流程不同，领域驱动设计统一过程并没有强制约定需求分析的方法，团队可以根据自身能力和方法的要求，选择用例需求分析方法，也可以选择协作性更强的用户故事地图或者事件风暴，甚至将多种需求分析方法与实践结合起来，只要能获得更有价值的业务需求。当然，为了让参与者能够在需求分析与管理过程中达成共识，也需要就需求术语定义“统一语言”。表3-2列出了统一过程使用的技术术语与主流需求分析方法使用的技术术语之间的对应关系。

表3-2　需求分析的统一语言

 

领域驱动设计统一过程使用业务流程、业务场景、业务服务和业务任务4个层次的技术术语来体现不同层级的业务需求。

领域驱动设计对团队管理也提出了要求：“团队共同应用领域驱动设计方法，并且将领域模型作为项目沟通的核心。”^[8]6这一要求的目的是让团队成员更好地沟通与交流，并在团队内部形成一种公共语言，在开发节奏上保持与建模过程的步调一致。为了促进团队的充分交流，应为提供业务能力的限界上下文建立领域特性团队，为具有内聚功能的模块建立组件团队，针对客户端调用者尤其是前端UI建立前端组件团队，这种团队组建方式也符合康威定律的要求。

未完待续