领域驱动设计与微服务

DDD 微服务

摘要

在QCon伦敦大会上，Eric Evans提出使用领域驱动设计作为一种机制，在多个团队试图集成外部团队的服务时，妥善处理可能会出现的“大泥球”。

正文

在QCon伦敦2016大会上，《领域驱动设计》一书的作者Eric Evans提出，使用领域驱动设计（DDD）概念减少微服务环境中通用语言的复杂性。

团队使用不同的通用语言给管理微服务环境带来了特殊的问题。团队会开发自己的通用语言，并在自己的领域范围内赋予它们意义。然而，这些通用语言的概念在团队的语境之外并未保持一致。一个团队对“客户”的定义可能与另一个团队的定义存在明显的差别，导致了不必要的复杂性。此外，每一种语言都会在各自的团队内发展演变，几乎可以确定早晚会出现迥然不同的定义。

Evans谈到，团队会犯编码错误及误解需求，导致错误和糟糕的代码。虽然这时有发生，但最坏的情况是这些错误渗透到了其他不相关的微服务中。Evans区分了他所谓的“小泥球”和“大泥球”，前者是指问题包含在一个微服务中，后者是指一个微服务中的问题扩散到整个环境。

Evans介绍了三种可以帮助管理微服务环境的DDD工具：上下文映射、“防腐层（anti-corruption layer，ACL）”和“交流语境（interchange context）”。上下文映射代表微服务间的通信路径，暗含了微服务团队之间的适当交互。一旦这种分析成熟，团队就可以选择依赖不同团队的领域语言，在这种情况下，ACL可能就有意义了。ACL的职责是将外部概念翻译成内部模型，从而实现领域间的松耦合。在两个团队需要更多合作的情况下，交流语境可能更有意义。交流语境比ACL更完善，它提供了一个层，供两个团队讨论词汇意思，并来回翻译微服务语言。

将代码从单体应用移植到一个微服务系统会把上下文复杂性从代码转移到微服务之间的空间。微服务之间的交互现在包含了逻辑，这些逻辑以前存在于易于阅读和调试的代码中。这种新的上下文必须妥善管理，否则整个系统就会发展成为Evans所说的“大泥球”。

Evans建议，将每个微服务设计成一个DDD有界上下文。这为系统内的微服务提供了一个逻辑边界，无论是功能，还是通用语言。每个独立的团队负责一个逻辑上定义好的系统切片。最终，团队开发出的代码会更易于理解和维护。

查看英文原文：Domain-Driven Design and Microservices