hangsun的博客

在前面的《DDD 实战 (6)：战略设计之技术决策》中，我曾经提到“微服务随时可拆可分”。而在上篇《DDD 实战(11)：冲刺 1 代码 TDD 实现之道》几乎展示了所有 DDD 相关的、基于 TDD 代码“三部曲”的编程方式之后，就只上下这一个问题没有从代码角度进行演示了。本篇就来演示“微服务的随时可拆可分”这一 DDD 编程特性。同时，这将是本系列的最后一篇文章。

接上篇《DDD 实战 (10)：冲刺 1 战术之服务设计（下）及技术决策》后，我们接下来的重点，就是要展示真正的代码实现了。在本篇中，我将围绕 TDD（Test-driven development, 测试驱动开发）编程方法为核心，演示前面完成的相关 DDD 设计是如何落地的。 在本篇中，我将首先介绍 TDD 三重奏（写测试-写功能-重构）和相关原则，然后用实际代码演示 TDD 的工作流程，最后我会讲到编程过程中采用哪些技巧处理一些现实的技术细节问题。

接上篇《DDD 实战 (9)：冲刺 1 战术之服务设计》完成了“群买菜”系统 sprint1 服务设计的主要篇幅之后，本篇完成 sprint1 剩下的服务设计（主要是商品上下文），以及战术设计中需要进行的技术决策（这个只有第一次冲刺才需要）。

接上篇《DDD 实战 (8)：冲刺 1 战术之聚合设计》完成了“群买菜”系统战术设计的所有聚合设计之后，本篇将完成 sprint1 服务设计的主要部分（鉴权上下文、订单上下文）。

本篇开始我们对“群买菜”首个冲刺的战术设计进行描述。上篇《DDD 实战 (7)：战术设计、整体流程与首次冲刺》中，我们已经识别了首个冲刺的 14 个业务用例和 23 个服务契约的识别，并分别给出了相应的业务用例规约和服务契约设计。下面我们分两篇来分别完成：1）按照 14 个业务用例规约完成聚合设计；2）按照 23 个服务契约，在聚合设计的基础上，完成服务设计（含应用服务、领域服务）；3）作为首个冲刺，完成必要的战术层面相关技术决策（这一步工作一般只在首个冲刺的时候会做，后面的冲刺可能会有补充完善）。

上篇《DDD 实战 (6)：战略设计之技术决策》已经完成了“群买菜”的全局性（“全局性”的意思，是说整个系统只会有一次）战略设计。从本篇开始，我们就要进入实质性的系统实现过程了。这主要包括战术设计和代码实现。

篇《DDD 实战 (5)：战略设计之上下文映射和系统分层架构》完成了“限界上下文识别”和“限界上下文关系映射”这两个 DDD 战略设计阶段最重要的工作，甚至给出了代码目录结构，我们在 DDD 战略设计阶段就剩下最后一个内容：战略层面的技术决策。本篇就是要完成这部分内容。

在上篇《DDD 实战 (4)：战略设计之系统上下文和限界上下文》完成了限界上下文的识别（也就是系统“最粗粒度”的模块划分）后，我们需要对这些上下文之间的协作关系进行分析——即“限界上下文关系映射”。也只有在完成上下文关系映射后，我们才能真正的判定自己所做出的“限界上下文识别”是否真的达到了自己想要的“低耦合、高内聚”的目标。因为，通过“限界上下文映射”我们就能够看到：1）这些上下文之间有哪些协作关系？2）这些关系是强关联还是弱关联？

到上篇《DDD 实战 (3)：整体工作框架和全局需求分析》为止，我们已经完成了“群买菜”在“问题空间”的全局分析，本节开始进入“解空间”映射。我将用两节的篇幅来讲解“群买菜”的战略设计。首先，对战略设计的理论知识做一个浓缩性介绍；其次，分三节介绍“群买菜”的 DDD 战略设计，包括：本节介绍系统上下文定义、限界上下文识别；下节介绍“群买菜”限界上下文映射、系统分层架构；最后一节介绍群买菜“战略层技术决策”。

DDD 本质上是个“软件设计”方法论，它指导的是“怎么做软件设计”。故在正式开始“群买菜”的软件设计之前，我们先对 DDD 整体方法论做一个简单的、从我个人角度理解的介绍。

真正开始 DDD 旅程前，我想让您看到经过 DDD 设计之后的代码长啥样。我想，这是所有本着“talking is easy, show me your code”理念的程序员都比较在乎的观念。

通过本专题的旅程，您将能够理解 DDD 从需求分析、到架构设计、到编码实现的整个过程，以及其中的工作方法和实用技巧。