再来看第2段。
原文如下，我把会明显损害读者（及作者）利益的错误标红，并加上编号。
Imagine① a large, monolithic② system, classified as an ERP application. Strictly speaking, an ERP may be thought of as a single Bounded Context. However, since ERP systems provide many modular business services, there’s a benefit to thinking of distinct modules as different Subdomains. For example, we could divide the inventory module and purchasing module into separate, logical Subdomains. True, these modules aren’t available through completely different systems. Both are part of the same ERP. Still, each provides a very different set of services to the business domain. For analytical discussions③ let’s name these as separate④ Subdomains, the Inventory Subdomain and the Purchasing Subdomain. Continuing with the example, we’ll see why doing so is useful.
中译本译文：
①Imagine
原文只是说“想象”，译文的意思让读者以为是观察某个具体的系统。
②漏译monolithic
monolithic（单体），漏译了一个对DDD Fans这么重要的词，实在不应该。
当解决问题需要某个技能，而DDD Fans没掌握也不想学习以及没有能力学习该技能时，“单体”就是很好的遮羞布。DDD Fans只需要说：某某技能是用来做单体应用的，现在是革命性创造的DDD和微服务时代，这个技能过时了。
（前些年的借口是：我们现在采用敏捷开发，所以……。）
同理，他们对“××已死”这类话题特别热衷，因为如果××不死，他就得学习××来解决问题了。要认真学习知识，那真是比死还难受！
所以，如果你看到哪个社区在热烈讨论“传统的面向对象是不是已经过时”、“传统的关系数据库建模范式是不是已经过时”等话题时，千万不要轻易认为发起话题和参与话题的人已经掌握了“传统的面向对象”、“传统的数据库建模”，并且在特定的场景感受到了局限性，因此有感而发。
（注意，“传统”二字是很好的借口，意味着知识像食品一样，出厂时设置了保质期，到期则强制作废。）
事实极有可能是，这个人目前需要掌握他所称呼的“传统的**”技能，但他不愿意花时间去学习和思考，所以他需要一个借口来逃避。
如果你测一测他，不管过时不过时，你按照所说的“过时”的方法做一个给我看看？你看他会不会做吧？我这20多年来接触了几万开发人员，这个味道我太熟悉了。
感兴趣的读者如果碰到类似场景，可以试试看我有没有说中。
之前的文章我也写过：
③漏译一大片内容
True, these modules aren’t available through completely different systems. Both are part of the same ERP. Still, each provides a very different set of services to the business domain. For analytical discussions
以上这些漏译。
④separate意思未体现
应该是：命名为分离的子域。重点是“分离的子域”
中译本译文：分别命名为。separate变成了副词，担任状语来修饰“命名”这个行为。
相当于把原文变成了：
let’s name these as *** and *** separately（此处为说明问题，强行用了separate的变体，其实更合适的词是respectively）
--待续---
