从2019年开始，我发表了多篇领域驱动设计批评文章。
现在是2026年。在不修改原文的情况下，我逐篇加上2026年的一些补充评注，重新发布。
<原文发表于2021年3月20日>
Bruce 2021-3-19 15:20
老师，我看了一篇文章，里面提到领域愿景，感觉和您说的愿景不太一样，这两者有什么区别？
UMLChina潘加宇
【
202607补注：
先纠正可能会影响本文内容的翻译错误：
（1）"以便管理"，原文是for management。management在这里是管理层的意思，这句话其实是说"（愿景）为管理层而做"。
后文也有提到the management and technical staff，该处译文"管理层和技术人员"是正确的。
（2）"描述要尽量精简"，原文是Keep it narrow，意思是"保持聚焦"。
还有其他翻译错误，此处不提。
】
这个图应该是Eric Evans的《领域驱动设计》人邮译本里面的，你可以把它看作是"伪创新"。
Eric Evans给出的"领域愿景说明"例子，主语是领域模型，按道理是说分析？如果把"模型"二字替换成"系统"看看，更像是系统的需求，工件名字却叫作"领域愿景"。Eric Evans估计是不了解愿景、需求和分析的区别。
我们在2005年制作《领域驱动设计》中译本的时候注意过这个问题，这个内容一直没人提，就算了，但如果有人拿出来当典范来推，那就要好好说说了。
软件开发的一个迭代周期中的四个工作流：
A-业务建模------定位需要改进的目标组织（人群或机构）以及该组织接下来最需要改进的问题。
B-需求------描述为了改进组织的问题，所引入的信息系统必须具有的表现。
C-分析------提炼为了满足功能需求，所引入的信息系统需要封装的核心域机制。
D-设计------考虑质量需求和设计约束，将核心域机制映射到选定非核心域上实现。
Eric Evans的"领域愿景"相当于从C、D的知识去臆想A、B。
【
202607补注：
接下来看Eric Evans原文的问题：
（1）角色模糊
Eric Evans提到的角色有：
（项目团队的）非技术成员，nontechnical team members
（项目团队的）管理层，management
顾客（原译文"客户"），customers
"技术成员"、"非技术成员"、"管理层"的说法是模糊的。
例如，甲组织（目标组织）存在问题，需要改进，乙组织（开发组织）打算用本组织制作的系统给甲组织带来所需的改进。
乙组织中，研究和建模甲组织流程现状并寻找可能改进点（相当于上面的"A-业务建模"工作流）的人，是技术成员还是非技术成员？
"管理层"是甲组织管理层还是乙组织管理层？
"顾客"（目标组织、甲组织）也不是一个整体。甲组织负责人想要的改进很可能会损害甲组织里面某些岗位的利益。
（2）"技术人员"不用看"愿景"
Eric Evans批评以前的愿景声明（按DDD圈子口味可称为"传统愿景"），技术人员不去看，然后声称领域愿景声明（按DDD圈子口味可称为"革命性划时代愿景"）则是"技术成员"、"非技术成员"、"管理层"可以在任意阶段共享并用于指导资源分配等等，还提到"均衡各方利益"。
★愿景→领域愿景，这个造词手法属于《软件方法》所归纳的"加前缀"，参见《软件方法》1.5.3 造词（umlchina.com/url/softmeth.html）。
愿景是从目标组织（例如上面所说的甲组织）负责人的视角描述关于目标组织某指标的改进期望，开发组织（例如上面所说的乙组织）中的C-分析和D-设计工作流角色不需要知道愿景，他们只需要知道需求规约。这些（特别是D工作流角色）很可能就是Eric Evans所指的"技术成员"。也就是说，"技术成员"不看愿景是正常的。
愿景也不需要"均衡各方利益"。它连目标组织的"各方利益"都不管，更不用说开发组织的"各方利益"。进入C-分析工作流之前，开发组织是被当作不存在的。
读者如果不理解上面所说的，可认真阅读《软件方法》最新版（umlchina.com/url/softmeth.html）的第2章"业务建模 之 愿景"，花了整整一章来阐述愿景。该章目前统计共46,729字。
其中关键概念的类图如下：
（3）伪创新的诱人
这个地方也体现出伪创新的诱人之处。革命性划时代的"领域愿景"，它考虑了"技术人员"的利益！
前面20-30年间，互联网和信息行业的大发展，使得大量没有受过应有训练的人员成为了软件开发的"技术人员"。他们中的一部分人并没有"补课"的意愿和能力，而是致力于寻找可以让他们逃避辛苦学习的伪创新。
伪创新炮制者的动作，经常踩在这些"技术人员"的心尖上。伪创新炮制者推荐的"最佳实践"总是考虑这些"技术人员"的利益，怪不得这些"技术人员"接触到伪创新时，很容易喊"受用"！
过去二三十年，这些"技术人员"的利益绑架了软件工程的发展（参见《软件方法》第1章，umlchina.com/url/softmeth.html）。
幸运的是，AI的降临横扫了开发组织中这样的"技术人员"，但也要警惕，伪创新圈子已经开始通过各种手段污染AI。
关于伪创新，《软件方法》第1章专门有一节讲述------1.5 警惕和揭秘伪创新。
我用看病类比：
患者来到A医院看病，如果医院掌握了现代医学的检查和诊断手段，患者目前存在哪些问题，这个答案应该和具体的医院关系不大。
例如，经过认真检查，发现患者有：I期原发性肺恶性肿瘤，脑部缺血灶、混合痔、龋齿。
如果考虑了某些"技术人员"的利益，各种问题就来了。
"技术人员"觉得现代医学的检查和诊断手段太"重"，使用自己感觉"受用"的伪创新给患者检查和诊断，结论是：患者中邪了；
"技术人员"不擅长治疗脑部疾病，患者也不知道自己脑部有缺血灶或者没主动说，"技术人员"干脆就不提脑部缺血灶的事情；
患者其实已在或者已打算在其他医院治疗肺癌，此次来A医院主要是解决牙疼问题，但"技术人员"觉得有机会治疗肺癌对自己的简历有帮助，仍然花大量精力在肺癌上，对龋齿视而不见。
......
（4）莫名其妙的改进
抛开"内容里面有什么"、"谁该看谁不该看"这些问题不谈，我们看这个：
开头说，以前的vision statement没人看，也不说为啥就没人看；
接下来，改成DOMAIN VISION STATEMENT，这个问题就解决了。
凭什么呀？
**********
接下来是重头戏，我们来看看书中所给出的"领域愿景声明"示例的成色。
**********
（5）打哪指哪
这是没有受过真正软件工程训练的人容易出现的问题。不是指哪打哪，而是打哪指哪，想到什么写什么------这可是"灵感"，是自己的"巅峰"啊，不写下来一会忘了可不就损失大了？
《软件方法》第3章剖析了"打哪指哪，想到什么写什么"的现象。
书中的示例说，模型（原文The Model）这样，模型那样。我用前面定义的ABCD工作流来标注：A-目标组织，B-目标系统，C-系统内核心域，D-实现套路，得到下图：
可以看到，"模型"的内容是反复横跳、随意漂移的。
（5-1）模型可以表示出乘客的优先级和航班预订策略
这一句可以归入"C-分析"工作流，例如在类图上表达"乘客"、"乘客等级"、"航班"、"预订"等概念之间的关系。
Eric Evans在书中频繁使用的是"领域模型"，其实此处应该使用"分析模型"。
领域模型和分析模型有区别，下图来自《软件方法》第8章：
后文不再区分，把领域模型当作分析模型使用。
★DDD圈子对"领域模型"的使用也是混乱的。有时候指概念模型（相当于上面显示的《软件方法》图8-28），只说领域规律，和做不做软件系统无关。有时候又自豪地宣称，DDD的领域模型优越之处是更接近于代码实现（其实是被"技术人员"绑架的思维颠倒），这时就属于"D-设计"。
（5-2）并根据灵活的政策来平衡这些方面
作者可能为目标系统设想了一个"调整乘客优先级和航班预定策略"的功能，这属于"B-需求"工作流。
作者从C漂移到了B。
但这样表达不恰当。说领域模型有能力支持系统的这个功能，可以，但不能说领域模型自己有"调整乘客优先级和航班预订策略"的功能。
★这篇文章也谈到了来自DDD圈子的类似错误：功能！功能！功能！尽量不要搅在一起-《分析模式》漫谈53。
而且，作者写的还不是"调整乘客优先级和航班预定策略"，而是"根据灵活的政策来平衡这些"。
"根据灵活的政策来平衡这些"并不能成为"B-需求"的内容。什么叫"灵活"？
需求得这样写：
系统根据天气、可用资源、乘客优先级、目的地等因素计算最佳策略，计算最佳策略的规则参见****；
系统显示最佳策略，请求管理员确认
......
"根据灵活的政策来平衡这些"属于"A-业务建模"工作流。最多算A的素材，不算A的模型，严谨性不够。
根据我对这个圈子的了解，我大胆猜测，作者有可能是想写"B-需求"，但由于不太清楚A和B的区别，误写成A。
作者又从B漂移到了A。
目标是"灵活"，说明组织现在还不够"灵活"。你咋知道的？用什么指标来度量？现在的组织流程中，通过已有的软件系统以及人脑系统（员工）为什么没做到"灵活"？
这些属于"A-业务建模"要思考的问题。
要让某个指标达到"灵活"的标准，做法可以有：
*下放权力
可能这么一搞就能达到目的，不需要调整已有的软件系统和人脑系统，不需要引入新的软件系统。
*调整组织的现有流程
可能调整流程也能达到目的，仍然不需要引入新的软件系统。
*引入新的软件系统
采用这个方案，才有"B-需求"的出现。
（5-3）乘客模型应该反映出航空公司努力发展与回头客的关系这一点。
"乘客模型"属于"C-分析"，例如，"乘客"这个类相关的内容或者"乘客"上下文的类图。
"航空公司努力发展与回头客的关系"属于"A-业务建模"。当然，这样的表述质量很低，啥叫"努力发展"？它和之前的"根据灵活的政策来平衡这些"同属于A，但似乎级别还不同。尝试作图如下：
我把"根据灵活的政策来平衡这些"改成关于某个指标的阐述"调整政策所需周期太长"。
（5-4）简明的形式表示乘客的历史记录......
"简明的形式"似乎是说系统的某个界面设想，勉强属于"B-需求"。作者把领域模型（C）和某个界面上出现的视图（B）混在一起。
更下面的内容，读者可自行剖析。
**********
把不同级别的内容混在一起写，可以形成N*M*P的批量刷废话效果。
作者在示例中所写的"发展回头客"（A）、"乘客模型"（C）和"简明形式显示历史记录...（B）"只是"灵机一动想到赶紧记下来"的一条路线，可能还有其他路线，如下图：
每个存在关系的地方都照着A-B-C这样刷一遍，产出量就很可观了。
这就是伪创新的优势，Fans可以进可攻、退可守，按需调控产出量。
★"用户故事"受欢迎的原因类似，后面的"以便****"提供了跨级别批量刷废话的可能。
】
以下是回答的扩展。
有一些敏捷人士只有D的知识，在没有学习和掌握A、B、C的情况下，先高喊"砸烂一切"吸引热血青年，然后发现砸烂一切是不行的，又偷偷捡起自己砸烂的A、B、C，但又不好好学习其中的知识，只是从D来臆想A、B、C，就会得到各种伪创新，然后用"敏捷"包装起来到处宣传。很多"敏捷实践"实际上就是只掌握D的人怎么爽怎么来的实践。
这种现象值得警惕。因为"领域驱动设计"又是一个新的包装，有的"领域驱动设计"人士只有D的知识，然后用D去套A、B、C。既然"领域愿景"有了，"领域驱动设计特色的业务建模"、"领域驱动设计特色的需求"应该也不远了，没准已经有人在炮制了。
更麻烦的是，这些人士形成了一个互相吹捧的封闭体系。甲吹捧乙，乙吹捧丙，丙吹捧甲，偶尔搞一个"软件开发必读**"，里面全是封闭体系里的甲乙丙。