应对变化，不要吃错药[《软件方法》节选]

平时开发人员常说要“应对变化”，甚至有的人还喊口号“拥抱变化”，但我们需要认真想一想，要应对的是什么样的变化？

我列出各种“不好了，需求变了！”的情况如图8-7。

图8-7 各种“需求变化”

第一种情况实际上是最多的：需求其实没变，只是需求人员的“认识”变了。这种由于业务建模和需求技能太差导致的“需求变化”实际上是最多的。

要应对这样的“变化”，光是有分析和设计技能是没用的，需要提升业务建模和需求技能。这种情况和本章的内容就没有关系了。

*张三出现恶心、乏力、食欲减退等症状，村里的道士九叔给他诊断，认为他鬼上身了，需要搞一个驱魔仪式。九叔已经精研驱魔理论体系和实践多年，一手辟邪剑法已经练到星耀一级。

那也没用！因为张三得的是乙型肝炎。*

第二种情况是第二多的：功能需求变化，包括增加了一个用例、增加了一个步骤、输入输出的字段多了一项、某个步骤的业务规则做了调整……等。如果能恰当地建模系统要封装的核心域逻辑，使得核心域模型能精确体现核心域的内涵，会大大有助于应对这样的变化。

应对第二种情况，需要提升分析技能。

*如果充分了解肝脏的工作机制，当张三被诊断乙肝时，又观察到张三酗酒、熬夜，就可以预测很可能张三会肝硬化甚至肝癌，对应变是有帮助的。*

第三种和第四种情况发生得就没那么频繁：质量需求和设计约束发生变化，例如响应速度、并发容量、运行平台的更换等。

一些以“领域驱动设计”为名的文章，所举例子就1-2个领域类，然后就开始讨论Entity、Service、Repository、DTO、六边形架构……不是说这个知识没用，问题是软件组织缺的是这个嘛？

这些文章以为自己在说“领域驱动设计”，其实说的是“企业应用架构模式”、“互联网系统架构模式”。

强调“领域驱动设计”，背后暗含的意思应该是缺少“领域驱动”而不是缺少“设计”，结果呢？不谈领域，谈仓储、工厂。

在一些软件开发技术大会常可以看到这样的场景：某电子商务网站的架构师上台讲了一通，接着某视频网站的架构师上台也讲了一通，咦，两个演讲内容如此相似？原来，他们讲的都是自己系统中“域之间的架构”，而不是核心域内部的机制。究其原因也许并非不为，而是不能——架构师对自己所开发系统的核心域研究太浅。

许多“网红程序员 ”在网上谈论的内容大多是某种语言或框架的新特性，少有探讨他当前所开发系统的复杂领域逻辑，也是同样的原因：并非不为，而是不能。

---

---

---

---

---

---

---

---

---

---

---

---

---

---