软件方法（下）分析和设计第8章分析 之 分析类图——知识篇（20211227更新）
软件方法（下）分析和设计第9章分析 之 分析类图——案例篇（20211228更新）
平时开发人员常说要“应对变化”，甚至有的人还喊口号“拥抱变化”，但我们需要认真想一想，要应对的是什么样的变化？
我列出各种“不好了，需求变了！”的情况如图8-7。
图8-7 各种“需求变化”
第一种情况实际上是最多的：需求其实没变，只是需求人员的“认识”变了。这种由于业务建模和需求技能太差导致的“需求变化”实际上是最多的。
要应对这样的“变化”，光是有分析和设计技能是没用的，需要提升业务建模和需求技能。这种情况和本章的内容就没有关系了。
*张三出现恶心、乏力、食欲减退等症状，村里的道士九叔给他诊断，认为他鬼上身了，需要搞一个驱魔仪式。九叔已经精研驱魔理论体系和实践多年，一手辟邪剑法已经练到星耀一级。
那也没用！因为张三得的是乙型肝炎。*
第二种情况是第二多的：功能需求变化，包括增加了一个用例、增加了一个步骤、输入输出的字段多了一项、某个步骤的业务规则做了调整……等。如果能恰当地建模系统要封装的核心域逻辑，使得核心域模型能精确体现核心域的内涵，会大大有助于应对这样的变化。
应对第二种情况，需要提升分析技能。
*如果充分了解肝脏的工作机制，当张三被诊断乙肝时，又观察到张三酗酒、熬夜，就可以预测很可能张三会肝硬化甚至肝癌，对应变是有帮助的。*
第三种和第四种情况发生得就没那么频繁：质量需求和设计约束发生变化，例如响应速度、并发容量、运行平台的更换等。
一些以“领域驱动设计”为名的文章，所举例子就1-2个领域类，然后就开始讨论Entity、Service、Repository、DTO、六边形架构……不是说这个知识没用，问题是软件组织缺的是这个嘛？
这些文章以为自己在说“领域驱动设计”，其实说的是“企业应用架构模式”、“互联网系统架构模式”。
强调“领域驱动设计”，背后暗含的意思应该是缺少“领域驱动”而不是缺少“设计”，结果呢？不谈领域，谈仓储、工厂。
在一些软件开发技术大会常可以看到这样的场景：某电子商务网站的架构师上台讲了一通，接着某视频网站的架构师上台也讲了一通，咦，两个演讲内容如此相似？原来，他们讲的都是自己系统中“域之间的架构”，而不是核心域内部的机制。究其原因也许并非不为，而是不能——架构师对自己所开发系统的核心域研究太浅。
许多“网红程序员 ”在网上谈论的内容大多是某种语言或框架的新特性，少有探讨他当前所开发系统的复杂领域逻辑，也是同样的原因：并非不为，而是不能。
DDD浮夸，Eric Evans开了个坏头
我为什么写《DDD浮夸，Eric Evans开了个坏头》
[全文]DDD话语批评之一：评张逸的“状态和事件本质相同”
