本篇主要总结第五章：微服务架构中的业务逻辑设计
首先，作者介绍了传统的业务逻辑设计：事务脚本。作者不推荐这种设计，我们直接略过。领域模型模式才是本章的重头戏。
领域模型模式
领域模型：将业务逻辑组织为由具有状态和行为的类构成的对象模型。
领域模型模式，采用基于面向对象的设计，自带面向对象设计的优点。同时，面向对象的设计原则、设计模式也已经比较成熟，使领域模型设计更加容易上手、有迹可循。作者是相当的推荐，也是大多数中、后台或微服务采用的模式。
说到领域模型，肯定跑不了领域驱动设计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开始分布式事务处理
