领域事件

在 DDD 中，除了 命令 和 操作 之外，还有一个业务行为很重要：事件。

  • 通常发生后会导致进一步的业务操作
  • 在 DDD 中，称之为领域事件

什么是领域事件

如何识别领域事件

  • 用户旅程或者场景分析时
    • 捕捉业务/需求人员或者领域专家口中的关键词：
      • 如果发生 。。。。，则。。。
      • 当做完。。。。的时候，请通知。。。
      • 发生。。。。时，则。。。

领域事件使用最终一致性

  • 聚合设计原则：
    • 一次事务最多只能更改一个聚合的状态
    • 如果一次业务操作设计多个聚合状态的更改，应采用领域事件的最终一致性
  • 领域事件可以切断领域模型之间的强依赖关系

领域事件的技术实现机制

领域事件总体架构
图 1：领域事件总体架构图

领域事件的处理包括：

  • 事件构建和发布
  • 事件数据持久化
  • 事件总线
  • 消息中间件
  • 事件接收和处理

事件构建和发布

  • 事件实体；
    • 事件基本属性：事件唯一标识 / 发生时间 / 事件类型 / 事件源
    • 事件业务属性：事件发生那一刻的业务数据
  • 事件唯一标识：应该全局唯一

事件数据持久化

  • 用于系统之间的数据队长或者审计
  • 参考方案
    • 持久化到本地业务数据库的事件表中（利用本地事务保证业务数据和事件一致）；
    • 持久化到共享的事件数据库中

事件总线

  • 实现微服务内聚合之间领域事件的组件
  • 进程内模型

消息中间件

  • 跨微服务的领域事件使用

事件接收和处理

  • 微服务订阅方在应用层采用监听机制，接收消息队列的事件数据，完成事件数据的持久化之后再进一步业务处理

分层架构

概念

  • 最早是传统的四层架构（基础层是核心，但是，DDD 应该领域层是核心）
  • 进一步优化，实现了各层对基础层的解耦（领域层是核心了）
  • 领域层和应用层之间增加了上下文环境层，形成了五层架构
图 2：四层架构演化

四层架构
图 3：四层架构

用户接口层

  • 向用户显示信息和解释用户指令
  • 用户：真实用户 / 程序 / 自动化测试 和 批处理脚本

应用层

  • 很薄的一层，理论上不应该有业务规则和逻辑
  • 主要面向用例和流程相关的操作
  • 可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作
  • 同时是微服务之间交互的通道

领域层

  • 实现企业核心业务逻辑
  • 通过各种校验手段保证业务的正确性
  • 体现领域模型的业务能力，用来表达业务概念 / 业务状态和业务规则

基础层

  • 贯穿所有层
  • 为其他各层提供通用的技术和基础服务（第三方工具 / 驱动 / 消息中间件 / 网关 / 文件 / 缓存以及数据库）
  • 包含基础服务，采用依赖倒置设置，封装基础资源服务，实现应用层 / 领域层与基础层的解耦

分层架构最重要的原则

  • 每层只能与位于其下方的层发生耦合
  • 根据耦合的紧密程度可以分为两种：严格分层架构和松散分层架构

严格分层架构

  • 优化后的 DDD 分层架构属于严格分层架构
  • 推荐使用

松散分层架构

  • 传统的 DDD 分层架构属于松散分层架构

微服务架构模型

整洁架构

洋葱架构，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。

六边形架构


核心理念：应用是通过端口与外部进行交互的。核心业务逻辑与外部资源完全隔离，仅通过适配器进行交互。

小结

三种架构本质都是一样的，都是微服务架构高内聚低耦合原则的体现。这些模型是逐渐一点点继承和发展过来的，（六边形架构 -> 整洁架构 -> 分层架构？)