只凭经验，我们得经过遥遥辽远的汗漫之游，才能得到便利直捷之径。

——洛节·爱铿，转引自托马斯·哈代的《德伯家的苔丝》

距离领域驱动设计的提出已有十余年，开发人员面对的软件开发模式、开发技术和IT规模都有了天翻地覆的变化。即使领域驱动设计作为一种设计思维方式与软件设计过程，并未涉及具体的开发技术，但技术的发展仍然会对它产生影响，就连Eric Evans自己也认为：“如果在推行领域驱动设计时继续照本宣科地使用《领域驱动设计》一书，这就不太光彩了！”[1]

上次谈到

针对领域驱动设计现存的这4个不足，我对领域驱动设计体系进行了精简与丰富。精简，意味着做减法，就是要剔除设计元模型中不太重要的模式，凸显核心模式的重要性，并对领域驱动设计过程进行固化，提供简单有效的实践方法。

软件构建的过程就是不断对问题空间求解获得解决方案，进而组成完整的解空间的过程。在这个过程中，若要构建出优良的软件系统，就需要不断控制软件的复杂度。因此，我对领域驱动设计的完善，就是在问题空间与解空间背景下，定义能够控制软件复杂度的领域驱动设计过程，并将该过程执行的工作流限定在领域关注点的边界之内，避免该过程的扩大化。我将这一过程称为领域驱动设计统一过程（domain-driven design unified process，DDDUP）。

3.2.1　统一过程的二维模型

领域驱动设计统一过程参考了统一过程（rationalunified process，RUP）的二维开发模型。整个过程的二维模型如图3-1所示，横轴代表推动领域驱动设计在构建过程中的时间，体现了过程的动态结构，构成元素主要为3个阶段（phase），每个阶段可以由多个迭代构成；纵轴表现了领域驱动设计在各个阶段中执行的活动，体现了过程的静态结构，构成元素包括工作流（workflow）和元模型（meta model）。

不同于RUP等项目管理过程，领域驱动设计统一过程并没有也不需要覆盖完整的软件构建生命周期，例如软件的部署与发布就不在该统一过程的考虑范围内。结合领域驱动设计对问题空间和解空间的阶段划分、对战略设计和战术设计的层次划分，整个统一过程分为3个连续的阶段：

q全局分析阶段；

q架构映射阶段；

q领域建模阶段。

每个阶段都规定了自己的里程碑和产出物。里程碑作为阶段目标，可以作为该阶段结束的标志，避免团队无休止地投入人力物力到该阶段的工作流中；每个阶段都必须输出产出物，这些产出物无论形式如何，都是领域知识的一部分，并作为输入，成为执行下一阶段工作流的重要参考，甚至可以指导下一个阶段工作流的执行。根据情况，团队可以对每个阶段的产出物进行评审。每个团队可以设定验收规则，甚至做出严格规定，只有本阶段产出物通过了评审，才可以进入下一个阶段。

统一过程的每个阶段要执行的活动主要通过工作流来表现，一个工作流就是一个具有可观察结果的活动序列。整个统一过程的工作流分为过程工作流（process work flow）与支撑工作流（supporting work flow）。每个工作流都可能贯穿统一过程的所有阶段，只不过因为阶段目标与工作流活动的不同，工作流在不同阶段所占的比重各不相同，意味着在不同阶段花费的人力成本与时间成本的不同。图3-1中工作流图例的面积直观地体现了这种成本的差异。例如，价值需求分析工作流主要用于确定系统的利益相关者、系统愿景和系统范围，这些活动与全局分析阶段需要达成的里程碑相吻合，但这并不意味着在项目进入架构映射阶段时就不需要执行该工作。软件系统就像一座不断扩张的城市，通过价值需求分析获得的利益相关者、系统愿景和系统范围也会随着软件系统问题空间的变化而发生调整，其他工作流同样如此。

过程工作流构成了领域驱动设计统一过程的主要活动，它融合了领域驱动设计元模型，为工作流提供设计原则和模式的指导。这也使得整个统一过程保留了领域驱动设计的特征，遵循了“以领域为驱动力”的核心原则。支撑工作流严格说来不属于领域驱动设计的范围，但对它们的选择却会在整个统一过程中不断地影响着实施领域驱动设计的效果。领域驱动设计不能与它们强行绑定，毕竟不同企业、不同团队的文化基因和管理机制存在差异，但需要选择与领域驱动设计统一过程具有高匹配度的支撑工作流。

3.2.2　统一过程的动态结构

领域驱动设计统一过程的动态结构通过3个阶段，从问题空间到解空间完整而准确地展现了运用领域驱动设计构建目标系统的过程。这里所谓的“目标系统”是一个抽象的概念，取决于领域驱动设计统一过程的运用范围，既可大至整个组织，将该组织的所有IT系统都囊括在这一统一过程之下（问题空间的范围也将由此扩大至整个组织），也可小至一个已有系统的新开发功能模块，将其独立出来，严格遵循该统一过程，运用领域驱动设计完成其构建。目标系统的大小直接决定了问题空间的大小，自然也就决定了它所映射的解空间的大小。

1．全局分析阶段

全局分析（big picture analysis）阶段的目标是探索与分析问题空间。该阶段主要通过对目标系统执行价值需求分析与业务需求分析这两个工作流，完全抛开对解决方案的思考与选择，仅仅从需求分析的角度以递进方式开展对问题空间的深入剖析。整个全局分析过程如图3-2所示。

从价值需求开始，识别目标系统的利益相关者，明确系统愿景，识别系统范围。只有明确了利益相关者，才能就不同利益相关者的项目目标达成共识，以明确组织对目标系统树立的愿景，确保构建的目标系统能够对准组织的战略目标，避免软件投资方向的偏离。通过了解目标系统的当前状态和预期的未来状态，可以确定目标系统的范围，从而界定问题空间的边界，为进一步探索目标系统的解决方案提供战略指导。价值需求分析的成果看似虚无缥缈，似乎都是宏观层次言不及义的大话、套话，实则描绘了目标系统的蓝图，避免开发团队只见树木不见森林，缺乏对系统的整体把控。同时，它还指明了目标系统的方向，为我们确定和排列业务需求优先级提供了参考，为解空间进行技术选型和技术决策提供了依据，做出恰如其分的设计。

在价值需求的指导和约束下，根据用户发起的服务请求，逐一梳理出提供业务价值的动态业务流程，体现了多个角色在不同阶段进行协作的执行序列。每个业务流程都具有时间属性，通过划定里程碑时间节点，即可在业务目标的指导下将业务流程划分为不同时间阶段的多个业务场景。业务场景由多个角色共同参与，每个角色在该场景下与目标系统的一次功能交互，都是为了满足该角色希望获得的服务价值，由此即可获得业务服务。

在对业务需求进行深入分析后，可以结合价值需求分析的结果，将那些对准系统愿景的业务需求放到核心子领域，将提供支撑作用的业务需求放到支撑子领域，将提供公共功能的业务需求放到通用子领域，由此就可以从价值角度完成对问题空间的分解。

全局分析阶段的里程碑目标是探索和固定目标系统的问题空间，通过分析价值需求与业务需求，获得以业务服务为业务需求单元的全局分析规格说明书（参见附录D）。

参与全局分析阶段的角色包括客户或客户代表、业务分析师、产品经理、用户体验设计师、架构师或技术负责人、测试负责人。其中，客户、业务分析师、产品经理共同扮演领域专家的角色，并在本阶段作为关键的引导者和推动者。