《微服务架构设计模式》-学习总结05

本篇主要总结第五章：微服务架构中的业务逻辑设计

首先，作者介绍了传统的业务逻辑设计：事务脚本。作者不推荐这种设计，我们直接略过。领域模型模式才是本章的重头戏。

领域模型模式

领域模型：将业务逻辑组织为由具有状态和行为的类构成的对象模型。

领域模型模式，采用基于面向对象的设计，自带面向对象设计的优点。同时，面向对象的设计原则、设计模式也已经比较成熟，使领域模型设计更加容易上手、有迹可循。作者是相当的推荐，也是大多数中、后台或微服务采用的模式。

说到领域模型，肯定跑不了领域驱动设计DDD。下面一张图简单说明一下领域驱动设计干的事情。

领域驱动设计，Eric Evans在出版《Domain-Driven Design –Tackling Complexity in the Heart of Software》(中文名称：领域驱动设计——软件核心复杂性应对之道)一书中首次提出的简称Evans DDD。

作者简要介绍了DDD的两个设计阶段：

• 战略性DDD
  • 子域
  • 相关联的限界上下文
• 战术性DDD
  • 实体（entity）
  • 值对象（value object）
  • 工厂（factory）
  • 存储库（repository）
  • 服务（services）

然后，作者本章的重中之重就是介绍Aggregate——聚合模式。

聚合模式

聚合模式：将领域模型组织为聚合的集合，每个聚合都是可以作为一个单元进行处理的一组对象构成的图。

包括以下几个特点：

• 聚合拥有明确的边界
• 从数据库完整加载
• 删除聚合会从数据库中删除其对应的对象

聚合的使用规则：

• 只引用聚合根。聚合根是外部唯一可以引用聚合的部分，确保聚合能够强制执行各种不变量约束。
• 聚合间的引用必须使用主键。引用聚合必须通过标识（主键）而不是对象引用。
  • 使聚合保持松耦合
  • 避免出现跨服对象的引用
• 在一个事务中，只能创建或更新一个聚合。确保单个事务的范围不超越服务的边界。

紧接着，作者又推荐了另一个模式——领域事件。

领域事件

领域事件：聚合在被创建时，或发生其他重大更改时发布领域事件。

在讨论领域事件的过程中，作者提到了“事件风暴”的方法论。

事件风暴：一套通过协作，基于事件还原系统全貌，从而快速分析复杂业务领域，完成领域建模的方法。

学习总结

业务逻辑的设计，主要是使用领域驱动设计的方法。在微服务架构中，在具体业务逻辑的划设计上，作者推荐使用聚合模式和领域事件。运用前几章介绍的知识，综合分析一下Order Service的目前业务逻辑。

首先，以六边形软件架构风格为基础：

• 入站适配器
  • REST API
  • Order命令处理程序
  • OrderEvent Consumer
  • SagaReply消息适配器
• 出站适配器
  • 领域事件发布适配器
  • 数据库适配器
  • 出站命令消息适配器

其次，使用第4章介绍的Saga实现分布式事务*OrderSaga。

第三，使用DDD领域驱动设计中的聚合模型。将Order服务划分出几个聚合：

• Order聚合。代表消息者下的订单。包括以下几个部分
  • 聚合根：Order
  • 外部聚合（主键引用）
    • ConsumerId
    • RestaurantId
  • 值对象
    • OrderLineItem
    • DeliveryInfo
      • Address
    • PaymentInfo
    • Money
  • 方法
    • createOrder：创建一个Order并发布OrderCreatedEvent。
    • noteApproved/noteRejected：在CreateOrderSaga结束后修改订单状态
• Restaurant聚合

然后，使用OrderService承接各种入站适配器调用，并创建Saga，同时触发各种逻辑调用各种出站适配器。以创建订单为例：

• 首先查看承接订单的餐馆信息，如果查询失败抛出异常
• 调用createOrder静态工厂方法创建Order聚合
• 发布createOrder返回的领域事件
• 创建create order saga开始分布式事务处理