Eric Evans：DDD 不是为完美主义者而生

追寻完美设计是从一开始就伴随着领域驱动设计（DDD）的常见问题，但 DDD 不是为完美主义者而生的。最近在阿姆斯特丹的 DDD 欧洲会议上， Eric Evans 在其演讲中指出，为了停止这种追求，你需要对如何创建设计良好但并不完美的软件有一些概念，他还给出了一些这些年使用 DDD 的示例。

最早的 DDD 图书的作者 Evans 指出，限界上下文的最初目的是让我们认识到我们开发软件的开发环境相当复杂，它涉及许多遗留系统和其他的外部系统，以及可能带来影响的其他团队。在围绕软件的一部分的上下文中，你拥有概念上的一致性，在此特定的词总是意味着相同的事情。作为开发人员，你应该能够识别出你是否处于上下文的边界内，然后需要遵循特定于该上下文的规则。边界令你可以自由定义适用于那里的规则；不仅包括使用的术语，还包括架构和开发过程。Evans 指出，微服务应该是自治的，可以成为良好的限界上下文，但强调这一点并不意味着服务总是限界上下文，有时开发人员会把服务理解为限界上下文。

Evans 认为康威定律（Conway’s law）和限界上下文的概念之间存在一定的关联，他想创立一些东西来应用该定律。他举了一个例子，在一个系统中有两个上下文：一个负责信用卡，另一个负责现金帐户。这里我们在组织架构、子域和限界上下文之间取得了协调一致。但是现在，为关注细分市场进行业务重组，将商业帐户与个人帐户分离，并为每种帐户创建了一个团队。两个上下文保持不变（商业账户和个人账户都有信用卡和现金。译者注），现在两个团队都在这两个上下文中开展工作，时而发生的冲突意味着他们要协调他们的工作。他将这比喻为三足赛跑，为了提高速度，协调是必要的。在这种情况下，可能的风险是产生一个杂乱无章、随意堆砌的系统( Big ball of mud )，Evans 看到的一个常见原因是对软件开发缺乏清晰的管理。一个可能的解决方案是建立一个新的边界，使用防崩溃层（Anti-corruption layer）。

有时一个模型并不完备，不足以处理所要处理的所有情况。不是要创建一个能够处理更多情况却感觉很笨拙的模型，而是可以选择创建一个函数来处理模型未能处理的情况。这样的函数和许多if-then-else 语句一起工作，和任何高层概念保持距离以避免创建另外一个模型。不应该使用不完备的或难以理解的抽象。Evans 指出，最好使用if-then-else 语句而不是错误地认为要创建一个优雅的模型。创建这样的模型可能最终连能工作的模型都找不到。他认为追求一个好的但并不完美的设计是关于权衡的很好的例子。

Evans 不建议非得等到模型完美了才去使用它，那样的话我们将无法发布任何软件。我们必须忘掉这样的想法，即只要你在前期投入额外的时间去做设计，从长期来看就一定能得到回报。然而，我们不能走向另一个极端，只是堆砌一些可怕的东西并发布出去。如果我们在模型中有意识地做一些权衡，并具备一定的技能，在对已有模型不满意时知道该怎么做，将会得到更好的结果。

查看英文原文： Eric Evans: DDD is Not for Perfectionists

感谢冬雨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。