DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集
我把《软件方法》第1章的内容交给Nano Banana Pro，让它生成漫画。AI生成的漫画如下：
原文如下：
1.2.1 建模工作流ABCD
要做好需求和设计，从而低成本制造出好卖的系统，并非喊喊口号就可以，需要静下心来学习和实践一些必要的建模技能。
软件开发是增量、迭代进行的，每一个迭代周期都需要依次思考这么几个事情：
A-业务建模（business modeling）——定位需要改进的目标组织以及该组织接下来最需要改进的问题。
B-需求（requirements）——描述为了改进组织的问题，待引入的信息系统必须具有的整体表现。
C-分析（analysis）——提炼为了满足功能需求，待引入的信息系统需要封装的核心域机制。
D-设计（design）——考虑质量需求和设计约束，将核心域机制映射到选定非核心域上实现。
本书将以上ABCD称为软件开发的4个建模工作流。
每一个软件项目，只要不是故意摆烂，开发团队都会有A→B→C→D的推理过程——也许无意识、隐式地做，也许有意识、显式地做；也许推理过程严谨合理，也许推理过程漏洞百出；也许分成很多人来做，也许一个人做；推理产物的形式也许是UML模型，也许是其他……
很多开发人员只有D的知识。当岗位发生变化，需要他做A、B、C的工作时，按道理应该去认真学习A、B、C的技能才对。
可惜，很多人并不愿意走出自己的舒适区，甚至还会有意无意地把其他人拉到自己的舒适区。
例如，在和涉众讨论需求时，频频蹦出一些“技术潮词”，目的就是以自己的“所长”来碾压涉众，从而掩盖自己业务建模（A）和需求（B）技能的不足。
例如，在讨论核心域的类模型（C）时，动不动就谈到如何实现（D）或者质疑“会不会有性能问题”（D），从而掩盖自己抽象能力的不足。
于是，各种投其所好的伪创新就登场了。
有的伪创新极力贬低A、B、C的重要性，通过“砸烂一切枷锁”来吸引热血青年。例如，想那么多有啥用，最后不是还得写代码？张嘴就是Linus Torvalds的“Talk is cheap. Show me the code.”。
后来，“发明家”及其追随者慢慢发现砸烂一切是不行的，追随者的信念开始动摇。于是，伪创新不再贬低A、B、C，而是从D来臆想A、B、C，得到的A、B、C“方法学”非常“简单易学”，让只了解D的开发人员感觉“很受用”。
例如，深入第一线调研各类涉众的利益很麻烦。有办法，摆一个“现场客户”在旁边，开发人员就可以心安理得坐在电脑前面编码，有问题就推给“现场客户”。
例如，认真学习领域知识的各种概念和术语很麻烦。有办法，开发人员可以按照自己的理解创造一套“通用语言”。
伪创新往往并不会直接说自己简单易行，而是会说自己很高深。宣传中往往带有“艺术”、“禅”、“道”等字眼，有意无意地朝宗教、艺术、玄学方向引导——比起枯燥的数学理论和逻辑推理，这些东西可是太好下嘴了。还有一个很大的优势，一些媒体人听到“艺术”、“禅”、“道”等字眼就亢奋，自觉地加入到宣传伪创新的队伍中。
开发人员一开始以为很难很深奥，上手一学，发现其实不难！可以说是：投资少，见效快，产量高，门槛低，而且仪式感十足。最妙的是，不用走出舒适区辛苦学习，就得到了“方法学”，这可太符合只了解D的开发人员的胃口了！开发人员立刻有捡到了便宜的感觉，心中豪气顿生——不愧是我！别整三岁的，有能耐你整四岁的！
伪创新还会声明“领域驱动设计不是银弹”之类，也是为了进一步塑造形象。我都诚实地说了我不是满分，所以我前面塑造的90分的形象应该是真的。DDD
