DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集
★本文虽然从中译本译文错误说起，但重点不是翻译，而是原文。
有同学给我发过来一个图片，说是书里面截下来的，看不懂。
该图的说明写着：架构特征指系统必须支持的功能。
可是，上面所列的可用性、可靠性、**性、性能……如果对需求技能有所了解，一看就知道，这明明是非功能需求嘛！
（关于“非功能需求”的正本清源，参见《[答疑]“非功能需求”属于模糊术语吗》）
截图来自《软件架构：架构模式、特征及实践指南》，原书名其实是Fundamentals of Software Architecture: An Engineering Approach，显然，中译本“美化”了书名。
三位译者杨洋、徐栋栋、王妮都是Thoughtworks的员工。
这本书我之前翻过，但没有认真看，花这个时间不划算。如果我花时间认真看了这个圈子的某本书，那就不是看一看的问题了，还得好好写一写，否则不就白看了嘛。
因为碰到这个问题，我又找了这本书的原书和中译本来对照。
原书的这张图是这样的：
原来，“功能”这里，原文说的是“-ilities”，可以翻译为“某某性”，就是图中间列出的那些可用性、可靠性等等。
这些属于非功能需求，但是译者硬是翻译成“功能”，审校者也没有发现。
更有趣的是，这并不是孤立的现象。
我之前写过很多篇“《分析模式》漫谈”，已经做成了文集，下载地址：
[pdf]406页《分析模式》漫谈文集202606更新
umlchina.com/url/aptalk.html
其中有一篇《功能 功能 功能 尽量不要搅在一起》：
文章的内容是：《分析模式》2020年人民邮电出版社中译本，不管是facility、feature、capability还是function，都翻译为“功能”：
《分析模式》2020年人民邮电出版社中译本的译者，同样也是Thoughtworks的员工。
译文的问题还有很多，但这不是本文的重点。
本文重点也不是评价这本“架构”书的内容有多大价值，而是评价这本“架构”书的行文风格：演讲型的行文风格。
为了让听众听得爽、激情澎湃，书中大量使用绝对化的词，例如only、all、any、no……。
仅仅正文前两页，就有以下绝对化的不当表达：
这里只说最后一个，“那个时候所有基础设施（操作系统、应用服务器、数据库服务器等等）都是昂贵而且商业化的”，然后举了2002年的例子。
可是，LAMP这个称呼，1998年已经有了。
难道有LAMP称呼也白搭，就没人用LAMP？
我们把时间推得早一点来看：
1991年，Linux出现，1993年，PHP出现，1995年，Apache和MySQL出现。
1998年，LAMP的称呼出现。
此时正是互联网的第一波高潮，LAMP的发展没有理由突然在这里停住了。
如果“所有基础设施（操作系统、应用服务器、数据库服务器等等）都是昂贵而且商业化的”，像下面这本Apache书（中译本出版于1999年）卖给谁？
其他绝对化表达“架构师没有职业路径”、“行业对架构没有好的定义”、“架构师只处理纯技术的方面”、“任何定义过些年就会过期”，后面有时间再评点。
这个味道很熟悉。
我曾经写过一篇《DDD浮夸，Eric Evans开了个坏头》批评Eric Evans：
再来看国内的领域驱动设计书籍：
**********
以下是2023年Thoughtworks官网的截图：
上面说，Neal Ford演讲场数已经超过3,000场。这个是很了不得的数字。
Neal Ford还有一本著作《演讲模式》：
关于Neal Ford演讲强度的大小，我还写过一篇《[答疑]张学友和Neal Ford的区别》。
另一位作者Mark Richards，演讲方面的公开数据还没那么震撼：
这篇文章先说这么多，有时间再继续。
