从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。既然“领域愿景”有了“领域驱动设计特色的业务建模”、“领域驱动设计特色的需求”应该也不远了没准已经有人在炮制了。更麻烦的是这些人士形成了一个互相吹捧的封闭体系。甲吹捧乙乙吹捧丙丙吹捧甲偶尔搞一个“软件开发必读**”里面全是封闭体系里的甲乙丙。