在 QCon 伦敦 2016 大会上，《领域驱动设计》一书的作者 Eric Evans 提出，使用领域驱动设计（DDD）概念减少微服务环境中通用语言的复杂性。
团队使用不同的通用语言给管理微服务环境带来了特殊的问题。团队会开发自己的通用语言，并在自己的领域范围内赋予它们意义。然而，这些通用语言的概念在团队的语境之外并未保持一致。一个团队对“客户”的定义可能与另一个团队的定义存在明显的差别，导致了不必要的复杂性。此外，每一种语言都会在各自的团队内发展演变，几乎可以确定早晚会出现迥然不同的定义。
Evans 谈到，团队会犯编码错误及误解需求，导致错误和糟糕的代码。虽然这时有发生，但最坏的情况是这些错误渗透到了其他不相关的微服务中。Evans 区分了他所谓的“小泥球”和“大泥球”，前者是指问题包含在一个微服务中，后者是指一个微服务中的问题扩散到整个环境。
Evans 介绍了三种可以帮助管理微服务环境的 DDD 工具：上下文映射、“防腐层（anti-corruption layer，ACL）”和“交流语境（interchange context）”。上下文映射代表微服务间的通信路径，暗含了微服务团队之间的适当交互。一旦这种分析成熟，团队就可以选择依赖不同团队的领域语言，在这种情况下，ACL 可能就有意义了。ACL 的职责是将外部概念翻译成内部模型，从而实现领域间的松耦合。在两个团队需要更多合作的情况下，交流语境可能更有意义。交流语境比 ACL 更完善，它提供了一个层，供两个团队讨论词汇意思，并来回翻译微服务语言。
将代码从单体应用移植到一个微服务系统会把上下文复杂性从代码转移到微服务之间的空间。微服务之间的交互现在包含了逻辑，这些逻辑以前存在于易于阅读和调试的代码中。这种新的上下文必须妥善管理，否则整个系统就会发展成为 Evans 所说的“大泥球”。
Evans 建议，将每个微服务设计成一个 DDD 有界上下文。这为系统内的微服务提供了一个逻辑边界，无论是功能，还是通用语言。每个独立的团队负责一个逻辑上定义好的系统切片。最终，团队开发出的代码会更易于理解和维护。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论