“领域驱动设计”答疑（五）

Refactoring

问题： 重构项目如何借助领域驱动设计做指导？

简单地说：就是通过“领域建模”驱动对业务高效的学习和分析，并以“领域建模”驱动对软件更好的再设计和重构。

---

首先，围绕着领域建模来学习业务知识和既有代码，会更加系统和高效。

我们说软件开发是一个学习的过程。咨询师在面对陌生的业务和复杂的遗留代码时，通过建模相当于是对业务和既有代码的一个系统化的学习过程。领域模型是记录所学结果的最好方式，除此之外它还能在学习过程中时刻提醒优先去关注核心概念，以及指导应该在哪些还不一致的地方继续投入精力梳理，挖掘更本质的问题。

在过程中我会要求客户中对系统最了解的专家和我结对，也会抽时间自己一个人安静的看代码。我会画各种草图，然后再整理成UML，讲给客户专家获得他们的反馈，直到大家一致认可当前的模型设计基本可以解决对应的业务问题并满足代码改进目标。

具体到建模方法上，如前文所说，领域驱动设计并没有约束采用哪种方式。一般我用的最多的还是面向对象分析设计以及正交设计的各种原则和技术。

需要注意的是，很难一开始就能有完美的设计，就算有也应该需要花很长的时间，可能超出所有人的耐心。而且越是完美的设计落地难度越大，而没有落地的设计是没有产生实际价值的。

合理的做法是，先有一个大家认可的更好的设计，然后在重构过程中不断获得反馈，再去迭代的演进这个设计，让它逐步在落地的过程中趋于完美。

有了初始的领域模型后，接下来我们需要考虑新的设计如何落在当前系统里面，即如何将代码重构过去。这也不是能一蹴而就的，需要设计如何和既有系统兼容的演进式方案。我们不能只有high level的设计，还要和大家协商出一个可落地、可执行的演进策略。

再然后就是和大家pair programming，在重构的过程中逢山开路遇水搭桥，解决一个一个的问题，通过反馈再继续演进领域模型和代码。

这里要回答另一个问题：为什么没有用社区里很流行的事件风暴（Event Storming）建模方法？

“事件风暴”和“四色建模”都属于可视化的分析建模方法。尤其是“事件风暴”，适合团队一起参与，帮助所有成员快速达成共识。在建模过程中需要用到各种颜色的便利贴，按照一定的建模规则进行，所有参与者一起分析业务并得到初始的模型设计。

event storming

我在重构咨询工作中没有使用“事件风暴”，最主要的原因是 “我不会” ：）

在客户现场，大多时候只有一个业务专家能陪着我。大部分时间我只需要画画草图，和他安静的讨论就够了。我见过的顾问带着团队做事件风暴建模，最后取得的最大成果是团队所有人帮着顾问梳理和熟悉了业务。

最后，也是最重要的一点是，每种建模方式有自己的侧重点。事件风暴擅长于可视化引导取得共识，而不善于对复杂业务进行分析并对设计进行抽象。

对于新开发的项目，在尚不清楚未来的业务变化方向的时候，本着不过度设计的原则，可以基于初始的共识模型先进行编码以快速获得反馈，然后根据随后业务的变化逐步演进模型以及调整代码。

但是对于一个既有系统的重构项目，任何初始的分析模型，只是做到把业务映射到初始设计，帮助参与者达成共识，还是远远不够的。这样的模型可以作为起点，但还远不是终点。

好的模型设计是需要抽象的，是在抽象之后依然易于理解的，甚至更易于理解的。

既有系统的代码里沉淀了曾经业务面临过的各种变化，它们体现在代码中到处散布的条件分支判断中，体现在代码中到处的重复逻辑上，体现在每次新需求到来时的散弹式修改中。

代码里所有的这些点都是抽象的源泉！模型设计需要基于代码，识别业务的主要变化方向，分离不同的变化方向，建立抽象，从抽象的维度重新解构模型元素并寻求更本质的组合关系，从更深的业务洞察里为抽象的概念和关系找到更符合业务本质的设计。

而上述这些，大多数时候需要的是学习更多的业务文档，安静的阅读和分析代码，以及在需要的时候能找到相关的人进行深入的交流。

当我们能进一步得到一个兼顾易理解性和低成本响应变化的，更体现业务本质的领域模型，这才是指导既有系统重构的良好起点。

---

《“领域驱动设计”答疑（六）》

《“领域驱动设计”答疑（汇总）》