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

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

那么，让我们从“六边形架构”（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 — 具有聚合的领域模型

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