以下是这几年来针对《实现领域驱动设计》译文和原文的评点文章的汇集。
*****2019年8月*****
翻过前面的"译者序"，原书第一句的翻译就存在不少问题。
第一句原文：
"With Implementing Domain-Driven Design, Vaughn has made an important contribution not only to the literature of the Domain-Driven Design community, but also to the literature of the broader enterprise application architecture field.
第一句译文：
较大的问题：
（1）with......是"在……中"的意思吗？
（2）community的意思是"社群"，翻译成"领域"不合适。
（3）贡献是针对literature而说的，译文没有体现这一点。
较小的问题：
（1）important翻译为"卓越"，合适吗？
（2）"卓越的贡献"合适吗？"卓越"用于形容人物或才能，贡献是否用"卓著"？
（3）"宽阔"用于空间，表达所涉及范围应该用"广泛"更合适。
不是问题：
（1）field翻译为"领域"是可以的，不过本书的主要词汇之一Domain把"领域"这个词给占了，联想到上面的community也被译为“领域”，几个不同的词都译作“领域”，给人有偷懒的感觉。换另一个词更好一些，我也想不出什么好词，反正不能叫"字段"。
建议译文：
凭着《实现领域驱动设计》，Vaughn不仅为领域驱动设计社群，而且为更广的企业应用架构范围（？）的著作做出了重要的贡献。
或
凭着《实现领域驱动设计》，Vaughn不仅为领域驱动设计社群，而且为更广的企业应用架构范围（？）贡献了重要的著作。
再看第二句，问题还要更多。
第二句原文：
In key chapters on Architecture and Repositories, for example, Vaughn shows how DDD fits with the expanding array of architecture styles and persistence technologies for enterprise applications—including SOA and REST, NoSQL and data grids—that has emerged in the decade since Eric Evans' seminal book was first published.
第二句译文：
较大问题：
（1）SOA and REST, NoSQL and data grids，其中SOA和REST是一起的，对应于前面的architecture styles，NoSQL和data grid是一起的，对应于前面的persistence technologies，不应打散了一个顿号并列到底。这个地方应该不是译者故意发挥，而是没有看懂原文含义。
（2）expanding译成了"各种"，这个词的意思应该是"日益扩张"。我们耳熟能详的“……日益增长的物质文化需要，是****现代化建设的根本目标”里的“日益增长的”官方翻译是和这个差不多的growing。用这个词的意思是，就算各种新概念如雨后春笋般冒头，DDD依然适用。译成"各种"就变成了静态的了。
（3）array的意思没有体现。可译为"阵列"，对，就是RAID那个阵列，别译为“数组”就行。原文意思应该是SOA、REST、NoSQL、data grid这堆东西摆出来像阵列一样吓人，而且还在日益扩张。
（4）key翻译成"核心"不合适。
key和core不是一回事。key是钥匙，core是锁芯。我在网上找了个图：
（来自http://www2.diebold.com/ficcdsvdoc/TechPubs/books/tp-820984-001/tp-820984-001_fram.htm）
用面向对象的知识来说，对象的key是标识，对象的core应该是封装起来的。
当然，也许原文未必了解key和core的区别，就像我们平时说中文时很多用词顺口就说了，未必了解其背景。不过既然原文用了key，译者还是应该要尽量忠实原文。
较小问题：
（1）decade的意思没有体现。
（2）was first published里的first没有体现。原文加上first是严谨的，因为一本书如果受欢迎可能会印很多次。
（3）多了原文没有的“那本DDD”几个字。
（4）fit翻译成"融合"合适吗？是不是"匹配"更合适？
建议译文：
例如，在架构和仓储的关键章节, Vaughn展示了DDD如何匹配企业应用日益扩张的架构风格和持久技术阵列—包括在Eric Evan的开山之作第一次出版之后的十年间出现的SOA和REST，以及NoSQL和数据网格
**********
Jasmine 2022-8-7 19:54
有一个地方想和您商榷，这张图上说对象树是译者的臆想，我觉得译者译成对象树也对，因为聚合根和其他对象是一对多关系，您觉得呢？
******
以下不属于问题内容，属于回答者补充的背景：
此图摘自我写的《评“状态和事件本质相同”》，图中内容是《实现领域驱动设计》（Vaughn Vernon 著，滕云 译，张逸 审，电子工业出版社）中某段内容的英文原文和中文译文对照，加了一些批注。
关于此图的更多评论，还可以参见我的另一篇文章《猴子掰玉米？比较不同版《领域驱动设计》说“不变式”和“聚合”》。
******
UMLChina潘加宇
（1）
“对象树”在某些情况下是对的。
如果组合（聚合）关联的整体一端的多重性上限为1，也就是说，部分对象在同一时间最多只属于一个整体对象，那么这个整体-部分的对象链接结构确实是一棵有向树。
例如，图1左侧的类图就可能得到右侧形状的对象图（树）。
图1
如果一个部分对象可以属于多个整体对象（实际上这时整体-部分的含义已经模糊），那就是一张有向无环图，如图2。
图2
这意味着组合（聚合）是非对称的：如果对象B是对象A的部分，那么对象A不能直接或间接成为对象B的部分。
“间接”背后的意思是：组合（聚合）是传递的，如果对象B是对象A的部分，对象C是对象B的部分，那么，对象C是对象A的部分。
像图3是不允许的。C是B的部分，B是A的部分，也就意味着C间接是A的部分，那就不允许A同时也是C的部分。
图3
（2）
“对象树”有道理是不是意味着“译者译成对象树也对”？这个倒要好好说一说。
原文用词是graph of … objects（对象图），是不是译者像您（提问者）这样，想到了这一点，站得高看得远，然后毅然出手纠正作者，把译文改为“对象树”呢？
我们把这段译文一句一句仔细看看就知道了，看看译者（以及审校者）的水平是不是有三四层楼那么高。
（3）
原文：
Is an Aggregate just a way to cluster a graph of closely related objects under a common parent?
中译本译文：
聚合只是将一些共享父类、密切关联的对象聚集成一个对象树吗？
大问题：
“共享父类的对象”的说法在概念上是错误的。
我的剖析：
原文只是说under a common parent，“共享”属于译者自由发挥。
译者可能搞混了类和对象，搞混了集合和个体，看到原文的parent，误以为是“父类”（其实是整体对象），从而臆想出“共享父类”、“一个（应为一棵）对象树”的译文。
说“共享父类的类”或“类的对象”或“共享父类的类的对象”都可以，但不应说“共享父类的对象”。
“共享父类的类”的类图（不考虑多继承）如图4左侧的树，但是这棵树是“类（集合）”的树，不是“对象（个体）”的树。对象关系是像图4右侧这样的。
图4
以人举例，“共享父类的类的对象”是由若干“中国男人”对象、“美国女人”对象……组成的集合，它们的类的父类都是“人”。
读者可以自行体会"人有男有女"、"人有手有脚"、“人有车有房”、“人有高富帅有屌丝”的区别。
当然，作者此处用parent一词欠考虑，但还是尽量尊重原文，parent可译为“父对象”。
中问题：
related不是“关联”。
我的剖析：
“关联”一般指association，association一词在面向对象中有特定含义，组合（聚合）就是一种特殊的关联。
在问题所给图片中可以看到，在本句之后就有association出现，“can the associations be navigated……”，作者在这里用词还是很准确的。
related可以译成“相关”。
这个看起来像是个小问题，无非是译者用词比较随意，但并非如此。
Aggregate的各个部件之间只是相关（related），并不需要存在关联（association）。
以人举例，类图如图5：
图5
手、眼、心、肝这些部件和整体对象存在关联（组合关联），但它们之间并不需要存在关联，像图6这样：
图6
注意：我的用词是“不需要存在”。如果你要是执意要像图6这样做，也不是不可以，只不过是一个不良结构。
可能有的开发人员会想，图6有道理呀，这些部件之间有“兄弟”或“同事”关联呀！其实这些“兄弟”或“同事”是从整体-部分关联推算出来的冗余概念，系统不需要维护。
部件之间说“相关（related）”可以。
怎么个相关？静态上，它们都是人的部件，动态上，它们在某个场景中由整体对象协调来完成任务，如图7：
图7
*注意：可能某些部件并不需要参与某个场景，也就是说，图5中某些类的对象不一定出现在图7中（当然，可能会出现在其他场景中）。这个知识点，评点后面几句译文时还会再提到。
建议译文：
聚合只是把在共同父对象之下紧密相关的对象图聚集在一起的一种方式吗？
（4）
原文：
If so, is there some practical limit to the number of objects that should be allowed to reside in the graph?
中译本译文：
如果是这样，对于存在于这个树中的对象有没有一个实用的数目限制？
我的剖析：
这句的问题，主要还是之前提到的graph译成“树”以及“这个树”，还有allowed的漏译。
建议译文：
如果是这样，对于允许驻留在该图上的对象数目，有没有一些实际的限制？
（5）
原文：
Since one Aggregate instance can reference other Aggregate instances, can the associations be navigated deeply, modifying various objects along the way?
中译本译文：
既然一个聚合可以引用另一个聚合，我们是否可以深度地递归遍历下去，并且在此过程中修改对象呢？
问题一：
“遍历”属于概念不清。
我的剖析：
首先，原文用词的是navigate，意思是“导航”，并没有使用traversal、traverse等词。
traversal、traverse等词在计算机科学的特定场景中可译为“遍历”，意思是访问所有结点。
可是，整体对象在履行责任时，并不一定涉及其所有直接或间接的部分对象。注意，是“不一定”，需要“访问所有结点”的责任当然可以有。
如图8的类图：
图8
某个时刻的对象图可能如图9：
图9
在发生某次责任分配时，有可能只涉及到图9中的某些对象，不存在“遍历”，如图10：
图10（红色箭头表示责任分配）
最简单的组合关联就是类和属性了，在某次操作执行期间，对象并不一定要“遍历”其所有属性的值嘛。
问题二：
“深度地递归”属于概念不清和编造。
我的剖析：
原文是“navigated deeply”，译者也可能是看到deeply之后，想起有“深度遍历”，于是把navigated误解成“遍历”，然后来了一个“深度地递归遍历”。
“深度遍历”属于不严谨用语，都遍历了，无所不至，还不够深吗，难道还有“浅度遍历”不成？严谨的用语应该是“使用深度优先搜索（算法）的遍历”。
不过，为了省几个字，现在不只是口头交流，很多正式出版的书和文章也堂而皇之写“深度遍历”，这是很无奈的事情。
译者特地在“深度”后面插入了一个“地”，似乎说的又不是“使用深度优先搜索（算法）的遍历”，而是说要遍历得很深——又回到前面说的了，都遍历了，无所不至，还不够深吗？
但是再往下看，译者又在“深度地”后面自作主张加了原文没有的“递归”二字，变成“深度地递归遍历”，似乎又转回来了，还是在说“使用深度优先搜索（算法）的遍历”。
可惜，加的“递归”二字又是另一个概念不清。
“深度遍历”不意味着要“递归”，也可以“非递归”啊！
进一步展开来说，各种“递归”都可以改成“非递归”啊！
可能是加上“递归”二字觉得比较有格调吧。
问题三：
漏译了instance
我的剖析：
原因同前，类和对象的概念混淆。
建议译文：
Since one Aggregate instance can reference other Aggregate instances, can the associations be navigated deeply, modifying various objects along the way?
既然一个聚合实例可以引用其他聚合实例，那么关联是否可以向深处导航，沿途修改各种对象呢？
以下是扩展
Eric Evans在“Domain-Driven Design”一书中的很多地方提到关联时，使用了traversal一词，这带来了很多尴尬。
如图11的“Domain-Driven Design”原文：
图11
2005清华版中译本没有译成“遍历”，选择译成“导航”，如图12：
图12
2016人邮版中译本译为“遍历”，如图13：
图13
我现在的观点是，原文用traversal不能说不合适，这个词有很多用法，不能拿后来计算机科学的用法来绑架其它用法。
在翻译上，如果确实是计算机科学中“访问所有结点”的场景，就译成“遍历”，否则可以译成“游历”或其他词。
在这一点上，Vaughn Vernon要小心得多，他大量使用的是navigation，书中只有一个地方用到traversal——“traversal through deep object graphs”。
*****2024年2月*****
十多年前，我去北京某家单位讲课。
第一天结束后，主人家，也就是主张引进这个培训的领导——IT部门的A总，在附近请我吃饭。
互吹环节，列席的另外一位领导B总说，“我今天听了一节课，感觉对我们帮助很大啊，以后还要有劳潘老师……”，接下来的话让我的满脸笑容瞬间呆滞——“继续帮助我们推进敏捷开发”。
**********
上一篇关于《实现领域驱动设计》中译本的文章已经是2022年了。
本来不想针对这个写太多，其实我的观点是这些书连英文原版都不推荐看，更不用说歪曲得不行的中译本了，除非是负负得正，歪打正着。
但架不住偶尔就有同学把我当“领域驱动设计专家”，发个中译本的图片过来找我答疑“我正在学习领域驱动设计，有个问题……”。
于是，决定还是写一下。
该书真正的内容从第2章开始，我就从第2章开始评点。
评点1
原文
图1 Implementing Domain-Driven Design原文
原译文
图2 《实现领域驱动设计》译文
第2章一开头的翻译就出现了大问题，把作者的整体意思扭曲了。
①
three things是说三件要做对（get these right）的事情，不是说三个概念。
原文此处没有“概念（concept）”一词，纯属译者自行加戏。需要用到“概念（concept）”的地方，作者会使用的。例如，接下里的文字就有“all these concepts”，指的就是用粗体标出的“概念”。
我把things和concepts在图1中圈出。
这个错误引出了下面的大错误。
②
• What your Domain is
• What your Subdomains are
• What your Bounded Contexts are
原译文译成：
什么是领域，什么是子域，什么是限界上下文。
如果本章的主要内容是给出这几个概念的定义，那么这本书就应该叫《领域驱动设计》，而不是叫《实现领域驱动设计》。
其实作者的意思是：
你（严谨一些，应该是“你的系统”）的领域是什么？你的子领域是什么？你的限界上下文是什么？
作者是想讲述：怎样为你的系统正确地找到这些东西。
就像汪峰问：
你的梦想是什么？
要真实地回答这个问题并不容易。
也许你以为的梦想，其实是别人（例如家长）硬塞的。有的人甚至需要心理学专业人士的帮助，才能认清自己真实的梦想。
如果按照原译文这样译，就变成了汪峰做报告《什么是梦想》。
③
原文“discussed in detail（详细讨论）”被轻飘飘地翻译成“出现在”。
当然，Evans的书也没有“详细讨论”，这纯属圈子里的高情商商业互吹。
④
延续前面的错误，原文没有说“概念”。这里说的是把事情做对。
**********
译文可以改为
有三件事情，你必须非常清楚地了解：
你的领域是什么
你的子领域是什么
你的限界上下文是什么
不能只是因为[Evans]把所有这些概念放在后半部分详细讨论，就觉得它们是次要的。要成功实现DDD，你必须把这几件事情做对。
反转
还存在另一种可能，也就是上面所说的负负得正，歪打正着。
译者站在三四层楼这么高，比所有人都清醒，所以在译文中拨乱反正。
译者看清了本书没有像作者宣称的那样往前迈进一步，而只是重复了Evans书的内容，于是把译文写成“什么是领域……”。
同样，译者看清了Evans的书没有详细讨论这些概念，所以把译文改成“出现在”。
您觉得呢？
**********
接下来是“Road Map to This Chapter”。
我把原文和译文放在一起对照：
评点
①
只翻译了状语从句“by understanding Domains, Subdomains, and Bounded Context”，却没有翻译主体部分（谓语+宾语）“Grasp the big picture of DDD”，让人误以为本句的主体是“understand Domains, Subdomains, and Bounded Context”。
修正译文
通过理解领域、子域和限界上下文来把握DDD的全貌。
②
漏译了后半部分的恐吓“and why designing without it hurts”。
修正译文
了解为什么战略设计如此重要，以及为什么没有它设计会出问题。
③
漏译“practical”。
作者在“real-world（现实世界）”之外再加上一个“practical（实用）”，应该是强调案例对读者的实用性。毕竟现实世界的案例也可以举一个“法医颅骨复原”（最近刚好在刷《国民法医》），但离读者太远了。
修正译文
考虑一个有多个子域的、实用的现实世界领域。
④
漏译了修饰的短语"both conceptually and technically"。
修正译文
从概念上和技术上理解限界上下文。
⑤
译成“如何开始使用战略设计”，就枉费作者的一番心思了。
作者此处用“aha!” moment是训练有素，有bear来，可不是乱打的啊。
“aha!” moment有其特定含义，据牛津英语词典的追溯：
修正译文
看看SaaSOvation公司在发现战略设计时的“啊哈！”（顿悟）时刻。
当然，原文这样写也反映了圈子的风格，崇尚“啊哈！”（顿悟）的玄学，而不是汗水和逻辑。
**********
是不是译者特地在提纲部分译得比较粗糙，养精蓄锐对付正文呢？
遗憾的是，正文刚进入第一句，就把意思译反了。
原文和译文如下：
评点
译者可能对句子后半部的这两个it产生了误解，导致意思译反了。
我把两个it的所指标注在图中。
第一个it指的是organization，第二个it指的是是organization所做的事情what，即
an organization does [what] in [the world].
organization干活时，是在[the world]里面干的。
译者译成“其中所包含的一切”，就变成[the world]在organization或[what]里面了，意思刚好译反了。
修正译文
广义上，一个领域指一个组织所做的事情以及做事时所处的世界。
**********
不只是译文译反了，原文的“领域”定义也是错误的。
（1）“领域”指“组织所做的事情”？
原文说领域是“一个组织所做的事情以及做事时所处的世界”，听起来像下面这个：
这是个业务用例图啊！
业务用例是一个很大的价值，例如，波音公司“造飞机”。
“造飞机”可是一个高度综合性的事情，涉及众多学科的知识，自然科学的流体力学、热力学、航空工程、机械工程、材料工程、电子工程、控制工程、计算机科学……，非自然科学的经济学、管理学、人类学、心理学……
说“造飞机”是一个“领域”，这个“领域”是不是太大了？
哦，可以把“造飞机”看作大的“领域”，把流体力学、热力学、航空工程、机械工程、材料工程、电子工程、控制工程、计算机科学……经济学、管理学、人类学、心理学……看作“造飞机”的“子领域”嘛！
那大众公司“造汽车”，是不是也是一个领域？“造汽车也得涉及上面这么多学科，不过可能要把航空工程替换成汽车工程。
哦，同样，可以把“造汽车”看作大的“领域”，流体力学、热力学、汽车工程、机械工程、材料工程、电子工程、控制工程、计算机科学……经济学、管理学、人类学、心理学……看作“造汽车”的“子领域”嘛！
世界上形形色色的组织何其多，提供的价值何其多，而且还不断推陈出新，真的有那么多“领域”？
“领域”应该是比“做事情”更稳定、更基本的东西，像下图：
（2）“领域”是组织带来的？
“领域指一个组织所做的事情以及做事时所处的世界”，意思是“领域”是由“组织”带来的？
要是没有组织（organization），领域还存在吗？
一款贪吃蛇游戏涉及的领域，是什么组织在什么世界做什么事情？这个游戏有资格使用革命性创造和划时代洞见的领域驱动设计吗？
当然，此处可以用领域驱动设计投资少、见效快、产量高、门槛低、仪式感十足的特点回答，候选回答可以有：
*玩家组织在手机上玩贪吃蛇。
*贪吃蛇游戏的开发人员组织用开发工具开发贪吃蛇。
完美！
那如果横截面直径达100光年的γ射线暴袭击地球，人类灭绝（参见王诺诺的小说《故乡明》），领域（特别是和人类无特定相关的）还存在吗？
**********
接下来，我们来探讨一下领域是什么，领域、系统、组织之间的关系，并剖析原文这个错误定义背后所隐藏的DDD圈子通病：
没有能力、也不愿意下苦功学习如何理清系统所封装的领域逻辑，于是选择退到系统外“望闻问切”，试图来个“内病外治”，从外部来搞定内部。
如果系统外的逻辑也变得复杂，那么就转去搞"团队建设"，毕竟这是圈子真正擅长的。
**********
接下来，我们来看看领域和组织之间怎样能扯上关系。
很多学科都使用“领域（domain）”这个词，函数的定义域、网站的域名等等里面的“域”就是domain。
对于软件开发，domain指的应该是（软件系统需要封装的）知识领域（knowledge domain）。
（1）客观规律
宇宙、星系、星体、生命体、细胞、原子、基本粒子，当然，还有人类社会及其衍生物，万事万物都存在其运转的客观规律。
★无论人类存在还是已灭绝，无论人类是否认识这些客观规律，无论认识的精确度如何，这些客观规律就在那里。
（2）领域知识
经过不断积累和整理，人类对万事万物的认识形成各种领域知识，而且不断更新。有的更新朝着接近客观规律的方向，有的更新则有意无意地偏离客观规律。
虽然一直在进步特别是近200年进步飞快，但目前人类认识客观规律的总体精确度应该偏低——毕竟才0.7级文明嘛。
当前存在的领域知识中：
①有一部分知识精确度最高，例如各种最新的科学研究成果。
②有一部分知识曾经精确度最高，但现在已经被精确度更高的知识取代，例如阴阳五行、地心说。当然，至今仍然有很多人相信或假装相信这些知识的精确度很高——“****博大精深”。
③有一部分知识是基于①②，为了某种目的想象和杜撰的。
可以为了娱乐而杜撰，例如武侠小说中的武学知识体系、当代网络小说中的修真体系、游戏中的英雄技能体系。大家明知不是真的，但依然乐在其中。
还可以为了**而杜撰，例如（此处作者删除283字）。
从上面可以看出：
★领域知识虽然源于客观规律，但不一定接近客观规律或追求接近客观规律。
许多软件系统封装的是②或③的知识，例如一款看风水的系统、一款修真游戏。
★领域知识中，涉及到人类社会或人体的知识，只占很少一部分，而且精确度偏低。
领域知识是人类对万事万物的认识，而人类自身（甚至包括其他生命体在内）在这万事万物中能占多少比例呢？
目前人类能造出机器人，造出宇宙飞船，但无法合成（不是繁殖）出一个细胞，合成生命体更是遥不可及了。
★封装在软件系统中的领域知识，涉及到人类社会或人体的比例更少。
当前的绝大多数软件系统中，和现实中有生命的“人”对应的类，与其相关的逻辑所占比例是非常少的。封装复杂逻辑的类，我们需要为之画出复杂状态机的类，往往是“订单”、“设备”、“房间”等，它们在现实中对应的是无生命的事物。
目前的软件系统关注较多的人相关的逻辑可能是“有权限”、“无权限”等等，其他逻辑还没有能力或余力照顾。例如，现实中，男性很在意一名女性是否漂亮、健康、善良，但有多少软件系统封装了这些逻辑呢？
（3）系统
此处只讨论封装领域知识、有计算能力的信息系统，它能将输入信息转成所需信息输出。
信息系统可以分为人脑系统和非人信息系统（软件系统）。
人的大脑可以看作一台计算机，其中安装了许多信息系统。
例如，输入是一张人脸，输出是人的姓名，用人脑中的“人脸识别系统”辨认还是用计算机中的“人脸识别系统”辨认，本质是一样的。
注意，“封装领域知识”必须把相关的领域知识变成自己的计算能力。
人在身上揣一本数学书，或者大脑死记硬背这本数学书上的文字，却没有能力运用其中知识解数学题，那不算“封装领域知识”。
同理，计算机里放了一本数学书的pdf文件，也不算“封装领域知识”，因为也没有能力运用其中知识解数学题。
★无论有没有系统封装这些领域知识，这些领域知识都在那里。
还是用前面《“领域”的错误定义》的说法，γ射线暴啪的一下，人类没了，图书馆的书还在那里。如果“把字刻在石头上”，没准还能等来外星文明来阅读它们——参见阿瑟·克拉克的《星（The Star）》，三体的“把字刻在石头上”应该来源于此。
（4）组织
人脑系统，软件系统，以及其他非信息系统，可以组装成组织。
无论是否组装成组织，这些系统就在那里，领域知识也封装在系统里。
（5）组织价值（做某事）
可见，“组织做的事”和“领域”相隔如此之远，而且中间各个环节都是多对多的映射。从“组织做的事”来的定义“领域”是非常不妥的。
关于系统、组织的更深入论述，参见《软件方法》第9章。
**********
我们接着往下看。
①
原文
Businesses identify a market and sell products and services.
原译文
商业机构通常会确定一个市场，然后在这个市场中销售产品和服务。
评点
那么多句下来，终于有一句译文的意思没出现大偏差。译文自行加上了原文没有的“通常会”。
②
原文
Each kind of organization has its own unique realm of know-how and way of doing things.
原译文
每个组织都有它自己的业务范围和做事方式。
评点
（1）
Each kind of organization是“每类组织”，不是“每个组织”。
每个组织都有自己的做事方式，那可不得了。淄博那么多家烧烤店，天水那么多家麻辣烫，家家都有自己独特的做事方式？
要是能够全民真创新，自然是极好（往往也是极难）的。注意，是真创新，不是伪创新圈子的人人创新、个个造词。
（2）
漏译unique。
（3）
realm of know-how不是“业务范围”，而是和knowledge domain（知识领域）相似，但know-how比knowledge更碎片和非正式。如果实在找不到对应的译法，可同样译为“知识领域”，但本书中“领域”已经被domain占了，改成“知识范围”也行。
修正译文
每类组织都有自己独特的知识范围和做事方式。
③
原文
That realm of understanding and its methods for carrying out its operations is its Domain.
原译文
这个业务范围以及在其中所进行的活动便是领域。
评点
（1）
同前文，“业务范围”、“在其中”属于误译。
（2）
漏译its，特指这些东西是“它”——也就是特定组织——的“领域”，不能说这些东西就是“领域”。且不管原文是否有道理，这个漏译使得内容和原文产生了大的偏差。
（3）
漏译method。
（4）
此处更要谈一谈原文的问题。
作者在这里采用了很有领域驱动设计圈子风格的“换词”文风，把realm of know-how换成realm of understanding，把way of doing things换成methods for carrying out operations，确实是投资少、产量高、仪式感十足。
对应关系见下图：
carrying out operation的翻译根据上下文而定，如果是医院，可能指“做手术”，如果是商业机构，可能指“开展业务”。
这种车轱辘话，翻译是很为难的。
修正译文
该知识范围以及开展业务的方法就是它的"领域"。
扫一扫
163
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
