微服务模式：业务服务模式

无论是单体应用还是微服务，构建企业应用的业务逻辑/服务在更多方面上都有相似之处而不是差异。在两种方法中，都包含服务、实体、仓库等类。然而，也会发现一些明显的区别。在本文中，我将试图以概念性的方式强调这些区别，通过重新审视每种架构中内置的一些核心设计模式和原则。

那么，让我们从“六边形架构”（Hexagonal Architecture）开始，以及它与企业应用业务逻辑的关系。

六边形架构

任何企业应用中的业务服务理论上都在其核心使用了六边形架构

六边形架构/端口和适配器架构是一种用于软件架构设计的架构模式。它旨在创建松散耦合的应用组件，可以通过端口和适配器与其软件环境轻松连接。（维基百科）

图01 — 六边形架构

如图01所示，“业务服务逻辑”是六边形架构的核心。

领域模型模式

传统的过程式事务脚本模式通常是实现“简单业务逻辑”的一种很好的方式。

事务脚本模式：将业务逻辑组织成一组每个类型请求一个的过程性事务脚本。 但是，当实现“复杂业务逻辑”时，应考虑使用领域模型模式*，*基本上是使用面向对象设计（OOD）。

领域模型模式：将业务逻辑组织成一个对象模型，其中包含具有状态和行为的类[1]。

领域驱动设计（DDD）

然而，领域模型模式在典型的单体应用后端上效果良好，但在微服务应用中有一定局限性，这基本上由领域驱动设计（DDD）所覆盖。

DDD是对OOD的细化，它是一种开发复杂后端业务逻辑的方法。 使用DDD时，每个服务都有其自己的领域模型，避免了整个应用程序的统一领域模型的问题。

战略模式与战术模式

DDD提出了多种战略模式和战术模式。

其中两个关键的战略模式是子域（Subdomains）和有界上下文（Bounded Contexts）。这些模式通常有助于在应用程序中分解业务逻辑。

根据Vaughn Vernon的《实现领域驱动设计》一书[5]，子域存在于问题空间，有界上下文存在于解决方案空间。 换句话说，有界上下文帮助您管理应用程序中的复杂性，而子域则有助于组织和管理业务域的不同方面。 在实践中，有界上下文通常与一个子域对齐，但也可能在单个子域内有多个有界上下文，或者有一个跨越多个子域的有界上下文。 在每个有界上下文中，我们可以建立专门负责各自领域的团队来进行管理。这些团队负责构建给定领域的构件、需求、规范和服务。 战术模式基本上是您在服务中定义的领域模型的构建块。其中一些战术设计模式是实体（Entity）、值对象（Value Object）、工厂（Factory）、仓库（Repository）、服务（Service）和聚合（Aggregate）。 在本文中，我们将更深入地研究聚合模式及其在典型微服务设计中的用途。

聚合模式

聚合模式：将一个领域模型组织为一组聚合，每个聚合都是一个可以视为单元的对象图[1] 传统的领域模型是一个类和它们之间的关系的集合。在这个模型中，所有类和关系都是相互关联的，相对较难找到每个业务对象的边界，这是复杂微服务设计的关键要求。DDD中的聚合模式可以帮助您解决这个问题。 在聚合模式中，根据定义，将领域模型结构化为一组聚合使其边界显式并更易于理解。

图02 — 具有聚合的领域模型

每个聚合都有一个根实体（聚合根），可能有一个或多个值对象。

但这并不意味着一个聚合只能有一个实体。您可以在一个聚合中有多个实

体。但最佳实践是在一个聚合内有最少数量的实体，以提高每个事务的可扩展性。

聚合根是主要实体，它保存对领域模型中其他聚合的引用，并且是唯一一个可以用于直接查找的聚合中的实体。在聚合中的组件（例如值对象）将彼此间有对象引用。在图02中，您将看到这一点，每个引用的聚合主键ID都存储在主要聚合中，即聚合01。这允许在领域模型内部实现更松散耦合的架构。

聚合通常是从数据库完整加载（以避免任何延迟加载）。即使在它被删除的同时，聚合也会将其边界内的所有对象从数据库中移除。除此之外，将它们存储在像MongoDB这样的NoSQL数据库中更加简单。

简而言之，应用DDD聚合模式将：

1.将服务中的领域模型模块化。2.消除服务之间的对象引用（在DDD中，不同聚合中的类之间的引用是基于主键值而不是对象引用）。3.事务只能创建或更新单个聚合。这允许应用程序使用Saga模式更新多个聚合（我在之前的博客文章中详细讨论了Saga模式）。

聚合与Saga模式

Saga编排了一系列（微）服务中的本地事务，以保持数据一致性。每个本地事务都与一个映射的聚合相关联（参见图03）。

图03 — 连接聚合模式和Saga模式

聚合与有界上下文

在技术理论上，有关“有界上下文”和“聚合”之间的区别有一些误解。因此，了解它们之间的区别及其与微服务的关联至关重要。

如前所述，微服务可以通过“有界上下文”或“领域”来解释。每个“有界上下文”将有一个或多个“聚合”。

因此，在实践中，微服务不应小于一个聚合，也不应大于一个有界上下文。

图04 — 有界上下文与聚合

领域事件模式

在概念上，当聚合被创建和更新时，它们会发布领域事件。聚合知道其状态何时发生变化，因此知道要发布的事件。

这些领域事件最终作为消息发布到消息代理（例如Kafka）。

领域事件模式：当聚合被创建并且经历某些其他重要变化时，发布领域事件[1]。

事件风暴

有几种策略可以识别领域事件。其中一种流行的策略是事件风暴，可以通过一种研讨会形式的安排来执行，以了解具有许多事件的复杂领域。这种研讨会的最终结果是一个以事件为中心的领域模型，其中包含聚合和事件。