领域驱动设计(DDD)【28】之实践或推广DDD的学习

一 DDD的切入场景

• 在准备实践或推广 DDD 的时候，你的公司一般已经有自己的一套业务、系统、团队和开发流程。那么怎么把 DDD 切入到现有的研发体系中呢？

---

第一种是 新建系统。刚好有一个新项目，可能是要开发一个全新的系统，或者是为现有系统新增或重写一个比较大的模块。这时候领导希望保证质量，降低风险，觉得需要方法学的支持，可以采用DDD。

第二种是 改造现有系统。某个对公司很有价值的系统，系统年代久远架构和质量日益腐化，难以维护，不能满足快速变化的业务需求。希望引入DDD对系统进行比较大的重构，使系统重新“焕发青春”。另一种情况是企业要进行服务化改造，把一些现有的单体应用拆分成微服务。

第三种是 改进现有研发流程。公司未必想专门花一大笔预算新建或者改造系统，但领导已经意识到目前的研发流程有种种不足，如果再“野蛮生长”下去，会有很大的隐患。因此希望通过引入 DDD 等方法，提高研发水平和效能。

---

• 实践或推广 DDD 应该是“大处着眼，小处着手”。所谓大处着眼，就是认识到引入 DDD有益于公司的长远收益，并基于这种理念做宏观的长期规划。所谓小处着手指不能指望在短期内靠“运动式”地推广，让DDD大范围普及，而是要先选择若干个范围适中的项目和团队作为试点，取得经验后，再扩大战果、逐步推广。

二 试点项目和团队的选择

• 试点的选择，一定要把项目（需求因素和技术因素）和开发这个项目的团队（人的因素）一起考虑，不能孤立地考虑其中一个方面。
• 综合考虑“项目”和“团队”两方面，可以从关键因素来衡量：有价值、有痛点、有意愿和有时间。
• 有价值指站在企业的角度，这个系统对达成企业的战略目标有较大的意义；或者从业务角度，这个系统能够为公司带来比较大的收益。包括 DDD 在内的任何技术改进过程，都需要一定的成本。只有应用到价值较大系统，才能带来足够的回报。
• 有痛点指公司管理层或者开发团队确实遇到难以解决的困难，需求寻求方法学的帮助。“从痛点出发”是引入技术改进的重要思路。有了痛点，才容易制定改进目标，有的放矢，也更容易制定衡量改进效果的标准。痛点识别是否准确，往往影响着 DDD 的落地效果。
• 有意愿，指的是开发团队确实愿意学习新技能。其中，项目经理、开发组长、技术骨干等角色往往起着决定性的作用。我们引入一个新技能时，总有 20% 的人很想尝试；有 20% 的人比较抗拒；中间 60% “随大流”。在推广时，要想办法识别出前 20% 最有意愿的团队，先做出榜样，再带动其他人，就可以了。
• 有时间 也很重要。引入任何新技术，总会有些成本。包括学习成本、试错成本等。关键是看产出是否大于成本。这些成本初期往往体现为对开发时间的占用，要合理控制的成本投入。

三 新建系统注意事项

• 由于新建系统的历史包袱比较小，引入 DDD 往往比重构系统容易。但是在开发过程中一定要避免“瀑布型思维”。对于比较大的项目，前期的总体规划和设计还是必要的。但要意识到，这时候产生的模型还是方向性的、粗粒度的，之后开发过程中要随着对问题理解的深入，不断演进。除了从需求到模型，再由模型到编码的方向以外，在编码过程中发现模型的问题，反过来修正模型也很重要。另外，刚开始引入DDD的时候，架构师往往还不成熟，建模时就更容易出现错误，这时候更需要这种演进式的改进。

四 改造现有系统注意事项

• 对于引入领域驱动设计（DDD）而言，改造现有系统的实践比新建系统更为常见。这主要源于以下现实背景：多数企业在初创阶段通常采用野蛮生长模式，将业务快速落地作为首要目标，而往往忽视系统的内在架构质量。随着企业发展到一定规模，粗放式开发积累的架构缺陷（如逻辑混乱、维护成本激增、扩展性不足等）逐渐显现，此时改进现有系统的需求便成为迫切的业务诉求。在这种背景下引入DDD，本质上是通过领域建模和架构重构的手段，对已存在系统进行治理和优化。

---

改造现有系统的基本步骤大体上有 4 步：

1. 反推领域模型：从系统现状中“反推”出当前的领域模型，目的是客观地反映出系统当前的领域知识和逻辑。反推领域模型，可以从数据库、用户界面、代码等方面入手。一般是先看数据库，因为数据库里常常已经凝聚80%的业务知识。如果数据库看不明白，再看界面，如果还不明白，最后翻代码。阅读代码比较耗时，尤其是现有系统的代码往往很难理解。反推出的领域模型可以为进一步的改进建立“基线”。在反推的过程中所发现的问题，也可以作为下一步建立目标领域模型的输入。
2. 建立目标领域模型：根据当前系统的痛点、问题以及业务需求，就可以建立目标领域模型，作为改进的方向。建立目标领域模型，一定要有明确的“时间点”。这个目标是 1 年的、3个月的、还是 2 周的。脱离时间谈目标没有意义。越远的目标应该越宏观，越粗粒度；越近的目标应该越具体，越细致。过于长远的目标模型往往难以落地，所以要合理地设置目标时间。
3. 设计演进路线：根据当前模型和目标模型，分析两者之间的差距。跨越这个差距的过程就是改进的过程。设计演进路线最大的问题就是怎么保证可行性。一般要把改进过程化整为零，迭代实施，并且还要兼顾日常的业务需求。
4. 迭代实施：最好基于敏捷软件开发方法，小步快跑式实施。在这个过程中，必然会对之前建立的目标领域模型进行反馈，不断改进。同时还要不断评估开发现状，保证不偏离目标。

---

无 选择精益切片

• 首先选择系统中一个相对独立的小模块，然后按照前面的 4 步，尽快落地到代码并上线，建立最小闭环。通过这个过程，初步掌握 DDD 落地技能并取得实际效果。同时，积累经验，建立必要的开发流程。完成之后，再选择下一个切片，逐步扩大范围，并深化 DDD 的技能。这个相对独立的模块往往称为“精益切片”。
• 精益切片的难度、范围、风险要适中，最好在 3 个月内形成最小闭环。

六 改进研发流程的关键节点及注意事项

1. 需求创建阶段：协作建模，对于DDD成熟度较高的团队，建议在需求创建阶段（产品经理、BA等角色参与时）即引入架构师，共同完成领域模型、统一语言（Ubiquitous Language）和业务规则表的初步构建。
2. 需求梳理阶段：模型评审与优化，在需求讲解阶段（编码前），若已有初步领域模型，可同步进行评审与优化；若尚未建模，则由需求方与开发人员协作完成领域建模。
3. 系统设计阶段：模型一致性检查，针对复杂需求，需设立专门的设计阶段，确保技术方案与领域模型匹配，同时进一步验证模型的合理性。
4. 编码实现阶段：严格遵循模型，开发人员需基于领域模型进行代码实现及数据库设计，如发现模型问题，应及时反馈并调整。
5. 代码评审阶段：模型与代码一致性验证，在代码评审中，需重点检查代码是否符合领域模型，发现问题立即修正。
6. 上线及归档阶段：模型版本管理，系统上线后，应对领域模型进行规范化归档，并实施版本控制，确保后续迭代可追溯。

通过以上节点的严格把控，可有效提升DDD在研发流程中的落地质量。

DDD不是银弹，起码要经过几个月到半年的时间才能看到效果。很多团队还没有看到效果，就坚持不下去了。而将 DDD 融入研发流程，形成纪律，则可以保证团队坚持下去，直到产生明显的成效。

• “银弹”（Silver Bullet）在软件工程中是一个比喻，指某种能够快速、彻底解决复杂问题的万能方法或技术。这一概念源自西方传说中“只有银弹才能杀死狼人”，引申为“能一招制胜的终极方案”。

七 技术改进如何与业务需求并行推进

1. 问题背景：资源争夺的困境:许多团队在推进技术改进（如系统重构、架构升级）时，常面临与业务需求争夺资源的矛盾。若直接要求“冻结需求数月”进行改造，业务方通常难以接受，导致改进计划搁置。

2. 关键策略：渐进式拆分与持续交付 ：通过演进式架构和小步重构技术，可以将大规模改造拆解为多个独立、低风险的小任务，每个任务具备以下特点：

• 短周期：单任务可在几天内完成，不影响当前迭代交付。
• 无感知上线：改造过程不破坏现有功能，逐步优化系统。
• 累积价值：每完成一个任务，系统向目标迈进一步，而非等待“完美结果”。

---

3. 协作模式：平衡业务与技术的投入

• 时间分配协商：每个迭代预留一定比例（如 30%）资源用于技术改进，剩余聚焦业务需求。
• 任务穿插执行：将拆分后的小任务分散到多个迭代中，与业务需求并行处理。
• 目标对齐：投入比例需结合企业战略，由技术、业务、管理多方共同决策，确保改进可控且可持续。

4. 核心理念：磨刀不误砍柴工：通过这种方式，既能持续交付业务价值，又能逐步提升系统质量，最终实现“业务推进”与“技术优化”的双赢。

八 低配DDD

• 一开始可以聚焦在 DDD 最核心的问题上，暂时省略其他要点，推行一个“低配版”的 DDD。等到大家掌握了基本技能，需要更深层次的运用时，再引入其他知识点。

维度	建议和要求
领域模型（重点）	- 开始时可以只关注领域对象、关联以及模块的划分。 - 实体和值对象的区别、聚合、限定、泛化等等可以先不管。 - 规模不大的系统，也先不考虑限界上下文。
代码编写	- 一定要有领域层，其他方面可以先放宽。 - 领域层里的模块以及领域对象的名称和数量，要尽量和领域模型保持一致。确实不一致的地方，要有足够的理由。 - 应用服务和领域服务的区别，可以先不纠结，都写到应用服务里。 - 面向对象的封装、依赖倒置可先不要求，水平提高后再逐步重构。
其他交付物	- 为了贯彻统一语言，一开始就建立词汇表，并严格遵守。 - 业务规则表可以暂缓，但最好尽快建立。