1.三种最常见的切入 DDD 的场景

第一种是新建系统 领导希望保证质量，降低风险，觉得需要方法学的支持，因此要引入 DDD。

第二种是改造现有系统 某个对公司很有价值的系统，已经维护了很多年，系统架构和质量日益腐化，很难维护，不能满足快速变化的业务需求。

第三种是改进现有研发流程 希望通过引入 DDD 等方法，提高研发水平和效能。

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

2.试点项目和团队的选择

综合考虑“项目”和“团队”两方面，可以从这几点关键因素来衡量：有价值、有痛点、有意愿和有时间。

2.1 有价值

业务角度，这个系统能够为公司带来比较大的收益。包括 DDD 在内的任何技术改进过程，都需要一定的成本。只有应用到价值较大系统，才能带来足够的回报。

2.2有痛点

开发团队确实遇到了难以解决的困难，需求寻求方法学的帮助 有了痛点，才容易制定改进目标，有的放矢，也更容易制定衡量改进效果的标准。痛点识别是否准确，往往影响着 DDD 的落地效果。

2.3有意愿

在开始推广的时候，我们要想办法识别出前 20% 最有意愿的团队，先做出榜样，再带动其他人，这样就可以了

2.4有时间

引入任何新技术，总会有些成本。包括学习成本、试错成本等等。关键是看产出是否大于成本。这些成本初期往往体现为对开发时间的占用。

3.改造现有系统要注意什么

对于引入 DDD 来说，改造现有系统比新建系统更常见。这是因为，多数公司在初创的时候，往往是野蛮生长，并不注重系统的内在质量。发展到一定阶段，粗放式开发的弊病才暴露出来，也就有了改进系统需求。这时候引入 DDD，往往就是为了治理已经存在的系统。

3.1改造现有系统的步骤

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

3.1.1第一步是反推领域模型

反推领域模型，我们可以从数据库、用户界面、代码等方面入手。一般是先看数据库，因为数据库里常常已经凝聚了 80% 的业务知识。如果数据库看不明白，再看界面，如果还不明白，就只能翻代码了

反推出的领域模型可以为进一步的改进建立“基线”。在反推的过程中所发现的问题，也可以作为下一步建立目标领域模型的输入。

3.1.2第二步是建立目标领域模型

根据当前系统的痛点、问题以及业务需求，就可以建立目标领域模型，作为改进的方向。

3.1.3第三步是设计演进路线

有了当前模型和目标模型，就可以分析两者之间的差距。跨越这个差距的过程就是改进的过程。

3.1.4第四步是迭代实施

最好基于敏捷软件开发方法，小步快跑地实施。在这个过程中，必然会对之前建立的目标领域模型进行反馈，不断改进。

3.1.5选择精益切片

由于现有系统往往规模庞大逻辑复杂，如果针对整个系统反推模型，必然旷日持久。再加上建立目标领域模型的时间，可能半年就过去了。这段时间只有模型，没有任何落地的代码，也就看不到任何实际效果。于是人们往往失去耐心， DDD 无疾而终。

另一方面，在开始引入 DDD 的时候，架构师、领域专家、开发人员其实还没有真的掌握相关技能。只有落地到代码，形成闭环，才会有真切的感受，真正学懂 DDD。

所以，建议的做法是，首先选择系统中一个相对独立的小模块，然后按照前面的 4 步，尽快落地到代码并上线，建立最小闭环。

这个相对独立的模块往往称为“精益切片”。精益切片的难度、范围、风险要适中，最好在 3 个月内形成最小闭环。

4.“低配版”的 DDD

怎样在推广过程中降低 DDD 的难度。 DDD 的知识点还是比较多的，而且其中有一些理解起来有一定难度。如果在推广过程中，一下子就让所有人掌握所有知识点，往往会造成很多误解，导致动作走形，影响推广效果。所以，一开始可以聚焦在 DDD 最核心的问题上，暂时省略其他要点，推行一个“低配版”的 DDD。等到大家掌握了基本技能，需要更深层次的运用时，再引入其他知识点。

5.配套开发技能

为了保证 DDD 顺利落地，团队还要加强一些基本的开发技能，包括整洁代码、面向对象设计、代码重构、自动化测试，持续集成、持续交付，以及进一步的 DevOps 等等。

此文章为3月Day4学习笔记，内容来源于极客时间《手把手教你落地 DDD》