领域驱动实战思考（一）：用 TDD 思想对 DDD 的协作设计过程进行基准化

前言

在这一年聚焦 DDD 设计，尤其是 DDD 的协作设计工作坊的咨询工作中，我发现客户同很多咨询顾问之间总是存在以下冲突：

• 体验的“一致性”冲突

• 客户：希望不同的顾问在售卖方法论的时候解释能一致；

• 顾问：认为每个人对方法论的认识和理解本身就不同，很难做到一致。

• 服务的“标准化”冲突

• 客户：希望顾问能够将所售卖的方法论进行标准化；

• 顾问：认为顾问所售卖的方法论本身非常灵活，需要 By Experience 依据不同的情况进行适配，标准化是做不到，并且也是不应该做的。

结合我曾经在 ThoughtWorks 近 4 年的人员培养和教学经验，和这几年来的咨询经验，我能够理解客户这样要求，是因为希望能够实现方法论的规模化落地。而在方法论规模化落地的过程中，一个很重要的问题，就是绝大多数能力一般的人，都更习惯于依据“明确的指令”进行工作，而不是依赖自己“有限的经验”和“莫能两可的方法论”。

这篇文章就是记录我是如何来解决这个问题的。

对 DDD 这样的方法论进行“按部就班”式的基准化梳理，从而形成“基准化的操作”，以提供“明确的指令”，说起来简单，做起来却没有想象中容易。绝大多数的顾问虽然能够对方法论进行阶段性拆分，但是却没有能够将方法论进行细粒度的拆分和验证。

从我的观察来看，之所以造成这个问题，主要原因来自几个方面：

• 对方法论的深入研究不够：在售卖方法论的时候，现学现卖。

• 缺乏反复的思考和打磨：缺乏机会进行反复验证和优化，或者注意力不够聚焦。

还有一个很重要的原因，就是绝大多数技术顾问可能脱离写代码这件事情太久了，没有意识到对方法论基准化非常像我们开发软件的过程：

• 首先，都是需要从客户需要出发，明确交付目标的价值和内容。

• 然后，以 Tasking 思想和阶段性验收条件为着眼点，将目标拆解为不同的阶段。

• 接下来，对每个阶段进行细化的实现，保证每个阶段的验收条件在实现过程中可以通过最简单的方式达成。

• 最后，产出第一版最小基准化内容，通过不断的适配和打磨，进行迭代式的改进，或者较大幅度的修改（类似需求变更）。

更重要的是，以上这个过程，是可以用“测试驱动开发（Test Driven Development）”的思想来做的！

利用 TDD 的方式进行 DDD 设计过程的基准化

那么，我是怎样用 TDD 的思想，对 DDD 的设计过程进行基准化的呢？在这一年，通过大大小小十数个咨询项目，我是这样做的：

• 第一步，我通过在不同客户项目的实践中打磨和定义了每个阶段清晰的输出件，产出了《DDD 工作坊准入条件和产出物图例》。这一步就相当于通过 Tasking 确定程序的输入和输出，以及定义测试驱动开发中的测试用例。

• 第二步，在确定了输入输出后，我继续通过不同项目的不断打磨，基准化了每一个阶段的操作步骤，并把每一步细化到概念介绍、操作步骤、过程图例、要点提示四个部分，产出了《DDD 工作坊操作手册》。这一步就相当于通过测试驱动的方式，进行了程序“处理”过程的实现，并且还通过小步迭代的方式，对操作过程进行了一遍又一遍的迭代。

• 第三步，在整个操作手册完成之后，基于操作手册，重新梳理抽象出了适配这个操作手册的最简单和通常的概念，并从整个宏观上优化和定义了新的 DDD 分段式设计（战略设计阶段、战术设计阶段、技术实现阶段），解决了之前所有我所参与过的 DDD 培训所看到的知识体系凌乱，不统一，不顺畅等问题，让概念讲解部分最小化，产出了《DDD 工作坊概念讲解》课件。这一步就相当于程序设计和开发过程中，通过高度抽象，进行分层架构并实现架构演进的过程。

• 第四步，通过项目开发实践和进一步总结，结合多种以领域为核心的分层架构思想，不断打磨形成了适配整个基准化 DDD 的基准化代码样例。实现了代码化落地。

• 第五步，继续通过不断的实践、打磨和总结，产出《DDD 成熟度评估标准》。

这样，就通过实战验证的方式，从确定交付物开始，一步一步的增量式的完成了 DDD 设计过程的基准化，这也很像我们做软件设计时通过 TDD 而达到的“简单设计（增量式设计）”思想。

结果

DDD 的思想和设计过程，是公开并且没有什么保留意义的，所以，我在这里也选择分享给大家，以便为 DDD 在中国的落地和完善贡献一份力量。

同时，我也正在建立一系列的 DDD 基准化公开材料、社区和培训，我未来会将这些内容逐步发布到 Github 的“领域驱动”组织之中，地址如下：

• https://github.com/domain-driven
  

而文章中所说的基准化的领域驱动设计产出物如下，未来我会继续进行不断的打磨和优化：

• 《DDD工作坊准入条件和产出物图例》（提取码: 9jza）

• 《DDD工作坊操作手册》（提取码: uu1d）

• 《DDD工作坊概念讲解》（提取码: b4ft）

• 《DDD基准化代码结构样例》
  

• 《DDD 成熟度评估标准》(还在完善中，请期待)

对于这些基准化的产出，我已经通过带领 7 个新咨询师进行了可复用性的验证，这些新咨询师只需要通过我讲解或示范一遍，就能够独立承担后续的 DDD 设计咨询工作，并且还能够实现概念和手法的一致性。

至于“By Experience”，则只剩操作者个人经验的高低，和智商的天花板了。

作者简介

胡皓，ThoughtWorks 首席咨询师。十年以上软件开发工作经验。从士兵成长起来的软件技术顾问，从事过广泛的业务分析，项目管理，全栈软件开发、培训和技术咨询等工作。当前，作为 ThoughtWorks 中国区咨询 BU 数字化架构能力团队的负责人，正深耕于以演进式架构、领域驱动设计、云原生微服务为代表的数字化架构能力，帮助客户实现软件工程能力提升和数字化转型的目标。