领域驱动设计和微服务［翻译］

在2016年伦敦QCon大会上，《Domain Driven Design:Tackling Complexity at the Heart of Software》的作者Eric Evans提到在微服务环境下使用领域驱动设计的概念能够减少普遍存在的术语复杂性。

微服务的环境下，团队之间不相关的术语带来了明显的问题。一个团队将开发他们自己的术语并且在他们的领域范围内整理这些术语的含义。但是，在这个团队之外，这些术语不能维持一致性。一个团队对客户的定义可能与其他团队的定义不一样，这带来了不必要的复杂性。同时，每一个术语在所属团队内发展，几乎可以确认完全不同的含义将会存在于同一时间或者其它时间。

Evans谈到了团队编码失误和错误理解需求最终导致错误和糟糕的代码。虽然它只是偶然发生，但是当这个失误渗透到其它不相关的微服务时，最坏的场景将会发生。Evans阐述了他所说的“小泥球”和“大泥球”之间的区别，前者的意思是所有难题在一个微服务内，后者意思是一个微服务中的问题将会扩展到整个环境。

Evans展示了3个工具用于帮助微服务环境下的管理：上下文地图，ACL(反腐层)和交互上下文。上下文地图描述微服务之间的沟通路径并且建议微服务团队之间进行适当的交流。一旦这个分析是成熟的，一个团队可以选择依赖另一个团队的域术语，在这种情况下ACL层可能更清楚。ACL层的职责是把外部的概念翻译成一个内部模型从而提供了域之间的松耦合。在两个团队需要多个合作伙伴关系的情况下，交互场景可能更清楚。交互上下文比ACL更强大，它提供了一个两个团队可以来回的讨论他们的词语含义以及转换成微服务的术语的地方。

迁移代码从一整块巨石到一个微服务的系统是把一个上下文复杂性从一处代码放到各服务之间。现在微服务之间的交互包含了以前容易阅读和调试的代码中的逻辑。这个新的上下文必须是可管理的，或者整个系统转移到了Evans所说的“大泥球“中。

Evans建议根据领域驱动设计边界上下文设计每一个微服务。这将会在系统内部提供为微服务提供一个逻辑边界依据功能和术语。每一个独立的团队承担一份系统逻辑上定义好的部分。因此，团队产出的代码是更容易理解和维护的。

原文链接：Domain-Driven Design and Microservices