论领域驱动设计在微服务开发中的作用

在近期于德国柏林举办的 microXchg 大会上，来自 innoQ 的 Michael Plöd 在一场演讲中谈到了如何在开发微服务的过程中使用领域驱动设计（DDD）的话题。在他看来，微服务与DDD 之间的联系不仅仅只限于界限上下文（Bounded Context）的概念而已，虽然界限上下文确实是一种可用于定义微服务粒度的基础工具，但其他一些概念也同样重要。相应地，DDD 也并非只单纯地代表实体、值对象与repository 等概念而已。

Plöd 是 innoQ 的首席顾问。他相信，在创建微服务的过程中，DDD 可以在以下 4 个主要领域发挥作用：

• 战略设计 —— 这一阶段的主要工作就是界限上下文的设计，但上下文图（Context Map）与其他模式也同样十分重要。
• 内部构建块 —— 在设计一个界限上下文的内部结构时将用到 DDD 中的多种战术模式，例如实体、聚合以及 repository。
• 大比例结构（Large-scale Structure），通过有序演化与职责层模式创建结构。
• 精炼 —— 通过精炼方法，从一个已经成熟的系统中提炼出一个核心领域。

任何一个具有高复杂度的业务领域都由一个或多个界限上下文组成，每个上下文负责领域中的一部分内容。每个界限上下文都包含用于描述领域的模型，同时也定义了这些模型所代表的意义的边界。以一个客户对象为例，每个界限上下文都是按照独有的模型与视角来定义这个客户对象的。在 Plöd 看来，这一特性对于开发独立的微服务能够起到重要的促进作用。

上下文图描述了系统中的所有界限上下文，以及他们之间的相互关联及上下文之间的契约。Plöd 相信，对于已有打算进行微服务转型的组织来说，上下文图将带来极大的便利。不仅如此，上下文图还能够作为今后的转型过程中的一个良好的起点。以下是界限上下文之间常见的关系模式：

• 共享内核模式（Shared Kernel） —— 它表示两个上下文或模型之间共享某个领域的一个子集，包括代码在内。Plöd 提示，这种模式将增加系统的依赖。
• 客户 / 供应商模式（Customer / Supplier） —— 某个上下文将扮演客户的角色，它将从另一个扮演供应商角色的上下文中请求特性。
• 防崩溃层（Anticorruption layer， ACL ）—— 某个客户端将利用转换器（translator），将其自身的模型与其他模型进行隔离。在将系统转型为微服务或自包含系统（Self-Contained，SCS）架构时，这是一种非常有趣的选择，ACL 将表现为一个系统的护罩，以抵御来自外部的侵扰。

在 DDD 的各种内部构建块中，Plöd 特别提到了聚合的重要性。聚合是由多个领域对象构成的一个逻辑组，其中的对象将作为一个整体进行处理。聚合中的某个实体将成为聚合根，它负责接收所有外部请求，并负责整个聚合的生命周期。

对于僵硬的架构或是过于复杂的系统来说，可以选择创建一个跨界限上下文的大比例结构，让这个结构随着对于高层次概念的理解不断加深而逐渐进化。Plöd 表示，这一点也是微服务架构的核心思想之一，微服务的设计应当是可以不断进化的。职责层模式是另一种在界限上下文之内创建一个内部结构的结构模式，其思想是按照职责进行结构的创建，而微服务的结构也可以应用相同的概念进行设计。

在将某个遗留系统转型至微服务或是自包含系统架构时，精炼方法能够帮助开发者从一个现有的一体性系统中提炼出微服务。首先要辨别并提炼出核心领域，然后再通过迭代方法找出子领域，将其从核心领域中提取出来，最后再进行一些内部的清理与重构工作。Pödl 特别强调了为核心领域的业务功能与细节实现文档化的重要性。如果对于业务功能没有一个清晰的愿景及深刻的理解，就会增加无法发现最佳的界限上下文的风险。

Pödl 在演讲的最后回顾了以上概念，并在总结陈述中表示微服务与 DDD 能够很好地结合在一起。但他同时也提示，开发者应当具有大局观，而不是将注意力仅仅放在界限上下文中。

查看英文原文： Using Domain-Driven Design When Creating Microservices