DDD领域驱动设计批评-文集-点击查看>>
《软件方法》强化自测题集-点击查看>>****
8.1.8 伪创新
有的人（国内国外都有）没有掌握相应技能，也不愿意认真学习已有的知识，凭着一些朦胧的“领悟”，就“发明”了一些“新”方法，这就是伪创新。这样的人，国内国外都有。
软件开发的一些伪创新前些年打的是“敏捷”的旗 ，最近几年打的是“领域驱动设计”的旗 。仔细观察，背后推动的人很多是重叠的。
8.1.8.1 伪创新例一
图8-17摘自2017年出版的某本名字中带有“Domain-Driven Design”的书，我们来挤一挤这张图里面的水分。
图8-18 图中各元素的词性
咦就是UML的活动图吗用活动图表达不是更省事，干嘛非得自己“发明”一套p>
我们用UML活动图“复刻”一下图8-17，得到图8-19。
图8-20 删掉后缀
接下来再看“queue”，意思是事件通过一个队列传递（目的是解耦发送和接收），这个做法适用于各种不同核心域的系统，和“Place Order”、“Ship Order”所在的下单配送并不直接相关。把这个知识混进来，结果必然是废话刷工作量，如图8-21。
图8-22 删去非核心域知识
我们再观察图8-22，发现原来它在玩颠来倒去的文字游戏。用三个词：Place、Ship、Order，再加一个横杠符 “-”，换着花样组合，刷出了一批工作量。
组合技巧一：动词-名词+“Workflow”，放在活动（结点）处。得到“Place-Order Workflow”和“Ship-Order Workflow”。
组合技巧三：名词动词ed（注意，此处没有“-”了，又有了“新意”）+“event”，放在活动的输出针脚处。得到“OrderPlaced event”。
组合技巧四：动词名词（注意，此处没有“-”了，又有了“新意”）+“command”，，放在活动的输入针脚处。得到“ShipOrder command”。
剥去各种包装后，我们可以把这张图简化为图8-23。
图8-24 按照套路刷工作量示例
8.1.8.2 伪创新例二
图8-25摘自2019年出版的另外一本名字中带有“Domain-Driven Design”的书。展示的就是打着“领域驱动设计”旗 的伪创新之一：事件风暴（EventStorming）。
8-26 我提炼图8-25的概念画的图
有了图8-26，可以准备开车……不，准备刷工作量了！
（1）创建对象，销毁对象，刷2个蓝色纸片，就是图8-25中的Createan ad和Remove ad（怎么前面没有an了，刷得不整齐，重刷！）。
这个步骤刷出2个蓝色纸片。
（2）多重性为1的属性（从图8-25看应该是title、text和sell price），每个刷1个蓝色纸片，就是图8-25中的Change the ad title（怎么不和后面两个一致都用Update，刷得不整齐，重刷！）、Update the ad text和Update ad sell price（怎么前面没有the了，刷得不整齐，重刷！）。
这个步骤刷出3×1=3个蓝色纸片。
另外，本来这些都是Ad的属性，直接称title、text和sell price即可，不必再加前缀，但不加怎么能刷出工作量呢要加！
（3）多重性为多的属性（从图8-25看应该是picture和category），每个刷2个蓝色纸片，Add***和Remove***。
这个步骤刷出2×2=4个蓝色纸片。
另外，本来这些都是Ad的属性，图8-25中写Add***和Remove***即可，不用加to Ad、from Ad，但不加怎么能刷出工作量呢要加！
（4）每个操作刷1个蓝色纸片。
这个步骤刷出6×1=6个蓝色纸片。
（5）把（1）-（4）步产出的所有的蓝色纸片变换词序，每个旁边加一个橙色纸片。
这个步骤结束后，得到（2+3+4+6）×2=30个方框形状的纸片，或者说，15对。
（6）把图8-25中的4个小人和每对方框任意组合，得到大约15个黄色小人。
最终，我们从往墙上贴了30+15=45张小纸片，数量和内容正好和图8-25中的纸片相同。
信息浓度=16/45×100%=36%。再考虑到那些刷上去的Ad，估计差不多33%的浓度。或者说，图8-25的“事件风暴”中，有67%的水分内容。
要注意，这仅仅是其中一个类Ad，其他类照此办理，今年的工作量可算是有交代了。
8.1.8.3 伪创新为什么受欢迎
比起严谨的建模方法，伪创新更受欢迎，因为它迎合了“广大开发人员”呆在舒适区的需要。
如本书所言，软件开发的一个迭代周期中的四个工作流：
A-业务建模——定位需要改进的目标组织（人群或机构）以及该组织接下来最需要改进的问题。
B-需求——描述为了改进组织的问题，所引入的信息系统必须具有的整体表现。
C-分析——提炼为了满足功能需求，所引入的信息系统需要封装的核心域机制。
D-设计——考虑质量需求和设计约束，将核心域机制映射到选定非核心域上实现。
很多开发人员只有D的知识，当岗位发生变化，需要他做A、B、C的工作时，按道理应该去认真学习A、B、C的技能才对。
但是，很多人并不愿意走出自己的舒适区，甚至还会有意无意地把其他人拉到自己的舒适区。
例如，在和涉众讨论需求时，频频蹦出一些“技术潮词”，目的就是以自己的“所长”来碾压涉众，从而掩盖自己业务建模和需求技能的不足。
例如，在讨论核心域的类模型时，动不动就谈到如何实现或者质疑“会不会有性能问题”， 从而掩盖自己抽象能力的不足。
于是，投其所好的伪创新就登场了。
最开始的伪创新极力贬低A、B、C的重要性。例如，想那么多有啥用，最后不是还得写代码就是Linus Torvalds的“Talk is cheap. Show me thecode.”。
这就是之前的“敏捷”论调，高喊“砸烂一切枷锁”来吸引热血程序员。
但是，事实是残酷的。“发明家”及其追随者慢慢发现砸烂一切是不行的，追随者的信念开始动摇。
于是，新一代伪创新就登场了。
新一代伪创新不再贬低A、B、C，而是从D来臆想A、B、C，得到的A、B、C“方法学”非常“简单易学”。
不过，伪创新往往不会直接宣传自己“简单易学”，而是会说自己很高深。宣传中往往带有“艺术”、“禅”、“道”等字眼，有意无意地朝宗教、艺术、玄学方向引导——比起枯燥的数学理论和逻辑推理，这些东西可是太好下嘴了。
开发人员上手一学，发现其实不难！就像上面举的两个刷工作量的例子一样，投资少，见效快，产量大，而且仪式感十足。
最妙的是，不用走出舒适区辛苦学习，就得到了“方法学”，这可太符合只掌握D的开发人员的胃口了！开发人员有捡到了便宜的感觉，心中豪气顿生——不愧是我！别整三岁的，有能耐你整四岁的！
8.1.8.4 伪创新特点
造词
为了防止有人怀疑“天下哪有免费的午餐”，伪创新往往会造一个新名字，让人有“取得突破”的感觉，以进一步坚定追随者的信心。
造词手段可以是换词。例如，把“术语表（Glossary）”换成“通用语言（Ubiquitous Language）”。
造词手段可以是拼词。例如，在“愿景（Vision）”前面加上“领域（Domain）”，得到“领域愿景”（Domain Vision）。
如果人们得知一个东西曾经存在过，那么当这个东西再次被拿出来宣传时，人们会对宣传持有较多的理性，“这东西如果真的这么厉害，那之前怎么……”，宣传的人也会收敛，不至于那么夸张。
如果换一个名字，就会给人一种“全新”的感觉，人们可能就会给一个机会，毕竟是“新”的，没准人家真的有这么牛呢。
例如，说青霉素可以治愈肝癌，大众肯定不信，要是真的可以治愈肝癌那么多年不早就验证了嘛；如果把青霉素改个名字叫“K9527-α”，说可以治愈肝癌，可能就会有患者给它一个机会，买了试一试。
一个机会就够了！大不了这个词不好使了再换个词呗！
并不是说青霉素没有价值，杀灭细菌总是可以的。就算是淀粉做的假药，还可以起到充饥的作用呢。
危害在于，被误导的肝癌患者可能会将宝贵的金钱和时间资源优先用在了“K9527-α”上，耽误了获得更好治疗方案的机会。
割裂历史
伪创新会有意无意地忽略掉自己出现之前的某段历史，来证明自己的“进步”。
例如，“敏捷”的一些宣传中，一开始会描述“瀑布”如何如何糟糕，然后说“敏捷”如何如何比“瀑布”好，如图8-27：
图8-28 摘自Managing the Development of Large Software Systems（Royce W. W. ， 1970）
这样的宣传，抹杀了造词“敏捷”之前的软件开发过程所取得的进展，给不了解情况的开发人员留下“这是敏捷发明的，所以嘴上喊着敏捷的人最懂”的印象。
“领域驱动设计”的宣传也有这种误导，如图8-29。
图8-30 封闭圈子引用
例如，Eric Evans《领域驱动设计》的参考文献共25篇，图8-31是前17篇。
图8-32 学习体会和创新的区别
发表学习体会，包括错误的学习体会，当然没问题，这是个人自由，只要不把学习体会包装成“创新”就好。
***********
初中数学里要学习全等三角形、相似三角形、SSS、SAS……，到了高中以后学了正弦定理、余弦定理等解三角形的知识……就不会再回去用初中的方法解题了**。**
但是，不是所有人都能学会高中的知识，比如说张三。
张三可能会这样解释：
“我这个人能力比较弱，只能掌握全等三角形、相似三角形的方法。”
这样的说法没有问题。
张三还可能会这样解释：
“这个题目比较简单，用全等三角形、相似三角形的方法做足够了，而且这样更方便广大人民群众理解。”
这样的说法也可以。不过，竞争对手不是傻子，市场中哪里有什么”简单题目”！能带来利润的题目都很复杂**。**
但是，张三如果这样说：
“全等三角形、相似三角形的知识比高中三角函数的知识更深刻。”
这就是自欺欺人了。
更要警惕的是，有一个李四，也许和张三一样没有掌握高中方法，也许掌握了高中方法但是为了忽悠张三们，偷偷把”全等三角形”改名为”叠合三角形”，然后和张三宣传：
“我发明了”叠合三角形”新方法，比高中的三角函数有用，三角函数过时了。”
这就是可恶了。
***********
8.1.9 本书使用的分析方法
分析模型描述系统要封装的核心域知识。
至于用什么建模概念来思考和描述核心域知识，可以有很多种选择。例如，“人”用不同的建模概念描述，可以说它是一个“类”，也可以说它是一个“类型”、一个“实体”。
本书使用面向对象的建模概念来描述分析模型，从三个视角来描述：
分析类模型：描述系统中各个类以及类之间的关系。
分析状态机模型：描述某个类的各个行为的逻辑。
分析交互模型：描述某些类在实现某个用例时的协作。
而面向对象的分析模型的表达形式，也可以有多种选择：语音、文本、图形等。
有的人觉得当前许多编程语言的表达能力已经很强，认为用文本已经足够，抗拒用图形来表达领域知识。
但是，和只有自上而下顺序的文本相比，能够朝四个方向扩展的平面图形（如果有三维模型就更好了）更容易让建模人员看出领域概念之间的联系。例如，图8-33和8-34的内容，如果没有图形的帮助，直接用文本一行一行地构造分析模型，人脑的负担非常重。
图8-34 计算器的状态机图，摘自PracticalUML Statecharts in C/C++（Samek M. , 2008）
说到这里，又不可避免地要提醒，故意选择文本的形式来表达领域知识，有可能也是一种遮羞利器。图8-33和8-34的内容如果用文本表达，可能会得到很多页文本——这就有了理由：因为工作量太大了，所以很多地方无法做深入的思考，可以原谅！
本书使用类图、状态机图和序列图三种UML图形来表达面向对象的分析模型。UML类图表达分析类模型，UML状态机图表达分析状态机模型，UML序列图表达分析交互模型。
扫码或访问http://www.umlchina.com/book/quiz8_1_1.html完成在线测试，做到全对以获得答案。
微信：umlchina2
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！