从2019年开始我发表了多篇领域驱动设计批评文章。现在是2026年。在不修改原文的情况下我逐篇加上2026年的一些补充评注重新发布。原文发表于2019年3月11日我看到张逸老师在最近的一些文章中喜欢提老字例如我充分借鉴了事件风暴这种新方法却又未完全抛弃UML这种老方法若有可能我还希望再加上一个ICONIX方法虽然它已经垂垂老矣但该方法蕴含的一些设计思想仍有值得借鉴之处张逸老师的关注点从编码拓展到软件开发的全部工作流值得称赞。不过每个工作流有各自的技能需要学习是自己的感悟还罢了如果要传授技艺给他人更需要高标准严要求才对。所以我就用建模思维剖析张逸老师近期发表的一些内容供大家参考。就先从张逸老师上面这两句话开始吧。一、不是什么都叫方法上面这两句话张逸老师对各种概念一律以方法称呼之。其实UML是Unified Modeling Language是语言或者表示法Notation。ICONIX则是Doug Rosenberg等人提出的一种使用UML的建模过程Process。我们先来看2001年的著作图1 摘自Rosenberg, D., Scott, K., Applying Use Case Driven Object Modeling with UML: An Annotated e-Commerce Example. Addison Wesley (2001)再来看2007年的著作图2 摘自Rosenberg, D., Stephens, M., Use Case Driven Object Modeling with UML: Theory and Practice. Apress (2007)关于方法、过程和工具的定义可以参照被广泛使用的教材Software Engineering: A Practitioners Approach2014出了第8版。图3 摘自Pressman R., Maxim B., Software Engineering: A Practitioners Approach 8th Edition. SEM (2014)我于2008年写的《四十年软件工程故事》umlchina.com/book/se40.htm也可以参考。为什么对这些不当用词如此重视我在《为什么要对术语吹毛求疵》一文umlchina.com/qa/Content/906.htm中阐述了我的观点我们听到有人像上面的姨妈表哥一样说话时我们心里知道这可不是什么习惯用语不同而是说话的人是外行。因为我们是内行我们比姨妈表哥们更知道一些概念之间的区别。同理如果我们真的弄懂了软件开发中的一些重要概念当有人在我们面前说功能模块、用户需求、设计阶段等术语时我们心里就知道了这不是什么习惯问题而是这个人在某些方面是个外行。二、关于老人们对事物的认识会不断深入所以已有的知识有的会被继承有的会被淘汰。但是要注意之所以某些知识会被淘汰是因为人们针对这方面的知识有了更深刻的认识而不是因为法律规定这个知识只有**年**权到时间就要强行作废。几百年前的数学、物理知识大部分我们今天不还在继续学习和使用吗图4 摘自《中华人民共和国城镇国有土地使用权出让和转让暂行条例》【202607补注我在《分析模式漫谈合集》中的《“有传统”和王家卫》也谈了类似问题。《软件方法》1.5.4.1 偷梁换柱 有描述把比较难、懒得学的建模方法归为“传统方法学”把“领域驱动设计”吹捧为“新一代方法学”这些开发人员在谈论时把焦点放在“新一代”或革命性、划时代上心照不宣地假装自己对“传统方法学”已经熟悉到不屑一谈了。】既然张逸老师说UML、ICONIX老、垂垂老矣那我请问张逸老师能否具体说说看UML、ICONIX到底有哪些缺点看看能不能说到位但愿不是为了强调自己的新而随口一说。我不认为UML这个建模语言是完美的也不认为ICONIX这个过程的做法有多好。我甚至认为经过将近20年的积累对于建模和UML的下一步改进我的认识也许比起很多国外的人士更深刻。我还相信我在《软件方法》中提倡的过程比ICONIX以及其他一些类似过程要更高效实用。不过绝大多数软件开发人员基本上是赤手空拳根本没有达到被UML的不完美和ICONIX的不足绊倒的地步。事实上就算有人不使用UML里的图能熟练使用数据流图和实体关系图建模或者把能把ICONIX那几招用熟我觉得他就已经高出周围的人一大截了。NBA的格林可能清楚詹姆斯有啥缺点但这对业余球员来说有多少参考价值癌症的化疗、放疗有局限性和副作用是需要有更好的治疗手段但方向应该是更精细的免疫治疗而不是拿几味中药凑一凑得出来的癌必灵。三、痛点离问题域还有多远图5 摘自张逸文章《领域驱动战略设计暨微服务设计工作坊》域是一个面积或范围较大的概念点是面积或范围很小或近似于零的概念两者不能等同。也许张逸老师要表述的意思是通过痛点来判断哪一块领域需要建模。就像在人体按下痛点来判断哪一块区域需要深入研究。这样的表述更容易理解一些。即使换了表述也还是不准确因为从痛点到领域模型还有一段距离。头痛的问题未必在头。先列举一些建模知识点更详细内容请参见《软件方法》。★序列图消息的含义A指向B意思是A请求B做某事。例如图6中患者请求门诊收费挂号员办理挂号。如果发消息的是人接收消息的是非人智能系统意思符合A用B来做某事也可以。★业务工人Business Worker组织内的人员即人脑智能系统。★业务实体Business Entity组织内的非人智能系统。★业务流程信息化改进模式一物流变信息流模式二改善信息流转模式三封装领域逻辑通过下面例子来说明问题。某医院现在有个痛点输液反应的投诉比往年多了。这个痛点和需要改进的范围不是一一对应的。【可能原因一】有人组团碰瓷。【改进方案】1.1 引进一批记忆力好的高级保安业务工人盯牢每一个患者发现可疑人员报警如图6。图6 改进方案1.1引进业务工人1.2 如果一定要信息化改进可以应用改进模式三封装领域逻辑引进一套人物特征识别系统业务实体把监控人物特征的逻辑从高级保安的大脑转移到人物特征识别系统并争取和公安部门的业务实体对接。一旦检测到碰瓷党到来直接报警并通知挂号员如图7。图7 改进方案1.2业务实体替换业务工人由图7可以映射出人物特征识别系统的用例图也就是用例级别的需求如图8。补充上用例的涉众利益、路径、步骤、补充约束就得到完整的系统用例规约即以用例为组织形式的需求规约。图8 人物特征识别系统的用例图可能有的人会问这个系统应该还有其他用例吧例如有个人用这个系统来设置一下规则可能有也可能没有读者可以想一想为什么可能没有。不过再有100个也不影响因为每次迭代只需要关注最重要的用例永远都在路上。如果某个已有的非人智能系统已经提供了这个用例评估过后觉得确实满足需求的约定那事情到此为止不用操心后面的分析设计工作流了。如果没有现成的可用还是要做那就开始分析工作流。只要构造出来的系统履行了需求的约定按照哪种分析设计方法学来构造系统都可以。如果用面向对象分析设计方法学来构造系统我们假设系统由对象这样一种东西构成。在分析工作流系统中的对象在一个虚的对象空间中运行。这个空间不是内存也不是硬盘只是人脑中的一个逻辑空间。可能的分析类图如下图9 人物特征识别系统的分析类图不熟悉这个领域的逻辑仅属猜测【可能原因二】中国逐渐进入老龄社会老年输液患者的人数越来越多。【改进方案】2.1 不改进主管部门理解就行。2.2 在内部下密令医生开医嘱时留心看一眼HIS系统里的患者资料。针对老年患者开医嘱时尽量不要有输液内容如图10。图10 改进方案2.2-让医生业务工人判断是否老年患者2.3 如果一定要信息化改进可以应用改进模式三封装领域逻辑在现有HIS系统里添加一些逻辑医生在给老年患者开医嘱时HIS系统提醒一下如图11。图11 改进方案2.3-HIS判断是否老年患者HIS系统已有的用例开医嘱中会多一些步骤判断是否老年患者、提醒医生……和补充约束判断老年患者规则。HIS系统内部可以不增加新的类可以在原有患者类上增加一个操作判断是否老年患者在原有医生界面类上增加一个操作提醒医生有老年患者。【可能原因三】医院采购部门人员和厂家勾结为了获取回扣而购买劣质药品和器械。【改进方案】3.1 改进采购流程。例如集中采购权由采购办主任把关审查。图12 改进方案3.1-采购办主任把关3.2 如果一定要信息化改进可以应用改进模式一物流变为信息流改为通过信息系统传递采购申请取消各部门采购人员的责任应用改进模式三封装领域逻辑将采购办主任大脑里的审查逻辑封装一部分到HIS系统中如图13。图13 改进方案3.2-通过HIS系统传递信息由HIS系统封装领域逻辑从图13可以看出HIS系统多了两个用例图14 HIS系统多了两个用例要实现这两个用例可能的类图如下图15 HIS系统可能需要增加和修改的类【可能原因四】护士职业技能或职业素养存在问题例如对患者宣讲不到位无菌操作不到位没有根据患者差异调节输液速度等。【改进方案】4.1 加强培训加强监督加大奖惩力度。例如增加暗访人员图16 改进方案4.1-增加暗访人员4.2 如果一定要信息化改进可以把业务工人暗访员替换成业务实体监控系统事后安排监督员观看录像并评价。图17 改进方案4.2-引进监控系统代替暗访人员在市场上购买通用的监控系统应该可以满足需求。4.3 更进一步的信息化改进可以把护士这个业务工人去掉用业务实体超级输液机和无人运药小车代替。图18 改进方案4.3-引进超级输液机和无人运药小车从图18可以映射出超级输液机的用例图19 超级输液机的用例可能的类图如下图20 超级输液机的类图由上可见针对一个痛点可以有很多改进的可能。不同的可能中是否需要引进信息系统引进新的信息系统还是在原有信息系统上改进又有不同的选择。不管是哪一种选择推导的思路是清晰的。四、内外不分对问题域Problem Domain的误用图21 摘自张逸文章《领域驱动战略设计暨微服务设计工作坊》【202606补注根据这几年的观察这在DDD圈子中并不是孤例。根源应该是把“问题域”混淆成“问题”。这样的混淆从国外或国内的谁开始又是如何传播的路线不像“固定规则”的误译和误传那么好追溯。后续有时间再研究。“问题域”说的是问题所处的领域或者建模人员要聚焦研究的领域。它是“领域”不是“问题”。例如愿景是“缩短履行订单的周期”相当于张逸文章图中的“价值”经过思考认为解决这个问题可能需要聚焦于供应链领域。此时无论是1A-业务建模工作流描述履行订单的整个流程下单→分配仓库→拣货→复核→打包……还是2B-需求工作流描述其中某个信息系统的功能例如WMS仓储管理系统的“拣货员→拣货”功能相当于张逸文章图中的“功能”还是3C-分析工作流描述WMS里面的类拣货单、商品、库位。都属于问题域即供应链领域的内容。关于上面提到的“固定规则”误译和误传参见后来的DDD批评文章《你的医书是假的》和《就喜欢把不变式叫固定规则不行吗》。在2021年出版的书中张逸把用语改为“问题空间”和“解空间”。】当我们说起功能的时候研究对象一般是系统。对于组织一般说组织的服务对于类一般说类的操作。所以功能属于需求的范畴所以有术语功能需求描述系统作为一个整体为其他系统提供的服务。针对图21首先要说的是功能不是What是做某事。可以是下单可能是系统用例级别也可以是计算运费步骤级别。按照张逸老师的观点问题域是功能其他则属于解决方案域。如果用我之前所举案例的最后一种情况超级输液机套上去是不是应该如下图图22 按照张逸观点划分的问题域和解决方案域说到问题域估计2000年前后学习面向对象分析设计的开发人员会想到杨芙清、邵维忠写的《面向对象的系统分析》1998年清华大学出版社。当时开发人员学习OOAD的资料并不多这本书是当时很好的学习资料书中说到问题域时给出的都是如图22下半部的类图。当然作者写书的时候不是出版的时候UML标准还没出现书中用的是Peter Coad提倡的表示法。《面向对象的系统分析》我手边没有所以无法贴图不过杨邵跟随的是Peter Coad和Edward Yourdon的思想我们可以贴出Coad/Yourdon著作里的截图图23 摘自Coad, P., Yourdon, E., Object-Oriented Analysis, Second Edition. Yourdon Press, Inc. (1991)从图23可见书中用于描述Problem Domain的是类和属性。顺便把Coad/Yourdon著作里的What也贴一下图24 摘自Coad, P., Yourdon, E., Object-Oriented Analysis, Second Edition. Yourdon Press, Inc. (1991)可能有的读者会觉得上面的贴图说服力不大因为书的名字就叫Object-Oriented Analysis内容聚焦于分析工作流你咋知道其他书里Problem Domain主要说的不是需求哩我们再来看软件需求领域比较有名的著作Karl Wiegers等所著的Software Requirements。书中很少提到 Problem Domain正文第一次提到Problem Domain的截图如下图25 摘自Wiegers, K., Beatty, J., Software Requirements, Third Edition. Microsoft Press(2013)图25说的是数据字典更接近于类的概念而不是系统功能的概念。再看之前的ICONIX书正文第一次提到Problem Domain的截图如下图26 摘自Rosenberg, D., Stephens, M., Use Case Driven Object Modeling with UML: Theory and Practice. Apress (2007)同样涉及整个开发过程而且比Rosenberg等人的书更流行的应该是Craig Larman的书。我们也来看看Larman的书正文第一次提到Problem Domain的截图如下图27 摘自Larman, C., Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition. Prentice Hall (2004)最后来看Eric Evans的书。书中使用Problem Domain也比较少。正文第一次提到Problem Domain的截图如下图28 摘自Evans, E., Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley (2003)图28说的是非对象范型下的领域模型说的还是系统内的核心机制-分析而不是需求。说了那么多我的观点是说系统功能属于问题域是可以的但不能说问题域指的就是系统功能而把系统内部的核心域机制例如分析类、分析状态机排除在问题域之外。我更担心的是张逸老师可能犯了内外不分、需求和分析不分的错误。具体如何没有更进一步信息不便猜测大家可以看看我以下的文字有没有参考价值。我先说一下我对软件建模工作流的划分A-业务建模——定位需要改进的目标组织人群或机构以及该组织接下来最需要改进的问题。B-需求——描述为了改进组织的问题所引入的信息系统必须具有的表现。C-分析——提炼为了满足功能需求所引入的信息系统需要封装的核心域机制。D-设计——考虑质量需求和设计约束将核心域机制映射到选定非核心域上实现。以上四个工作流的名称使用了传统术语也有一定的模糊性特别是业务建模。更贴切的名称是组织建模、需求建模、核心域建模、实现。如果您觉得业务建模、需求、分析、设计不好直呼ABCD或改成阿猪、阿狗、阿鸡、阿鸭也无所谓。关键是要了解划分的依据一个是研究范围一个是研究内容。如图29。针对这些工作流的思考其实就是建模。任何一个软件项目这些思考都是逃不掉的也就是说我们一直在建模只不过很多人习惯于无意识地做运气时好时坏速度时快时慢有的人能够有意识地做让汗水不白流。思考的结果可以用口头表达也可以用文本、其他表示法或自造符号来表达。用UML来表达目前是一种不坏的做法。如果用UML表达推荐的用法如图29。可以看到工作流D可以不需要用UML表达。图29 各工作流思考内容和推荐表达再说一下核心域和非核心域的概念。一个软件系统封装了若干领域的知识其中一个领域的知识代表了系统的核心竞争力是系统和其他系统区分的关键所在。这个领域称为核心域其他领域称为非核心域。更通俗的说法是业务和技术但使用核心域和非核心域更严谨。核心域不一定是物流、医疗、金融等非计算机领域也可以是计算机和软件领域。问题域就是这里说的核心域。图30展示了不同系统的核心域和非核心域概念图30 不同系统的核心域、非核心域概念在软件开发中业务建模和需求工作流致力于解决系统好卖的问题分析和设计工作流致力于解决降低开发成本的问题。二者不能也不应直接映射。以常见的系统人体举例。人体的基本功能有走路、跳跃、吃饭等但是思考人体内部结构时不能从外部直接映射到内部得到人体由走路模块、跳跃模块、吃饭模块组成这样会导致大量的冗余。人体的模块是五官四肢和内脏还有最关键的——大脑。不管是走路、跳跃还是吃饭或者将来发展出更多的功能都应该尽可能复用这些已有的模块来协作完成。【202607补注更详细的阐述可以看最新2026版的《软件方法》第1章和第8章。umlchina.com/url/softmeth.html】还是以超级输液机为例。如果从需求直接映射到分析设计会得到很多无价值的类如下图图31 假面向对象抽象没有基本的面向对象抽象思维的开发人员即使使用面向对象的编程语言来编码也只是直接把系统的某个功能加上or或er作为类名称然后在这个××or或××er类的操作里写面向过程的代码。这样做表面上似乎是面向对象了实际上是换汤不换药没有得到面向对象的好处。想想也是理所当然的根本没有付出思考问题怎么会自己消失如果从分析设计出发来定义需求会得到一堆假的需求典型的就是××管理。就以张逸老师文章里的一张图为例图32 摘自张逸文章《领域驱动战略设计暨微服务设计工作坊》这些××管理怎么来的希望不是自内而外得来——先设想以后数据库里有客户表所以推导出系统有用例客户管理……。系统的需求应该从外面即组织的流程来映射可参见本文前面提供的业务序列图。再说一个现实生活的类比希望对理解前面的内容有帮助。面馆厨师擅长用若干种原料组件灵活组合出许多吃法用例卖给不同的顾客。同样是以面粉、肉、菜、蛋为主原料面馆可以提供馒头、包子、花卷、烧饼、饺子、馄饨、锅贴、烧麦、春卷、油条、发糕……拉面、刀削面、擀面、擦面、哨子面、扯面、油泼面、担担面、拌面、焖面、面疙瘩、揪面片、手擀面、拉条子、炒面……臊子面、沙茶面、茄丁面、酸菜面、鸡蛋面、虾仁面、牛肉面……我去面馆就餐点了一碗馄饨过了一会老板端来一碗饺子。我说老板这是饺子不是馄饨老板肯定不能嘲笑我笨饺子和馄饨98%是一样的都是面粉和肉菜的组合制作工艺也差不多你就将就着吃吧。要是这样我会扭头就走因为隔壁还有面馆这个最关键。老板可以把饺子端回后厨经过快速分解重新组合几分钟之后饺子变成了馄饨然后又端出来给我。我并不了解馄饨哪里来的只要味道比隔壁的好价格又公道我就吃呗。当然绝大多数的面馆没有把已经煮好的饺子分解再组合快速变馄饨的黑科技多半是用新的原料重新快速做一份馄饨。但软件开发的原料复制起来并不需要钱啊五、需求、分析……是阶段吗……【202607补注省略号是原文就有的不是本次补注删除了内容。也就是说没写完。后来也没有继续写下去。此处我有看错。张逸使用“需求阶段”、“需求分析阶段”不是出现在本文重点批评的2018年文章而是更早的博客园文章《解剖PetShop》。在2018年文章中张逸已经把“阶段”用于横坐标部分不再使用“需求阶段”等。】有的读者反馈不一定非得按照你说的吧有自己的方法不行吗答1不懂得我说的这些知识糊里糊涂地做事。2懂得我说的这些知识仔细思考过后还是决定按照自己原有的风格做事。这两者不一样。只要读者您不是第1种本文的目的就达到了。来而不往非礼也。我写的《软件方法》以及三年之内的公众号文章当然也包括本文也欢迎张逸老师和各位读者批评指正。【202607补注可以改为10年之内了。】