4. 领域事件基础：什么是领域事件、事件溯源思想、事件与消息的区别
领域事件（Domain Event）是领域驱动设计（DDD）战术模式中的核心概念，也是连接业务逻辑与消息基础设施的桥梁。理解领域事件的定义、溯源思想及其与消息的本质区别，是构建事件驱动架构的前提。
4.1 什么是领域事件
领域事件表示领域中发生的、对业务有意义的、且领域专家关心的事实。它记录的是“已经发生的事情”，而非“将要发生的事情”。
- 不可变性：事件一旦发生，其记录不可修改。
- 业务含义：事件名称必须使用通用语言（Ubiquitous Language），如
OrderPlaced、PaymentReceived。 - 时间戳：每个事件都携带发生时间，用于追溯和排序。
- 上下文：事件通常包含聚合根ID、事件版本、关键业务数据。
关键原则：领域事件是“事实”的载体，不是“命令”或“请求”。命令（Command）表示意图，事件表示结果。
4.2 事件溯源思想
事件溯源（Event Sourcing）是一种持久化策略：不存储聚合的当前状态，而是存储导致状态变化的所有领域事件。系统通过重放事件序列来重建聚合的最新状态。
| 对比维度 | 传统状态持久化 | 事件溯源 |
|---|---|---|
| 存储内容 | 当前快照（最新状态） | 事件流（所有变更记录） |
| 数据恢复 | 从数据库读取最新行 | 重放所有事件重建状态 |
| 审计能力 | 需额外审计日志 | 天然完整审计轨迹 |
| 时间旅行 | 不支持 | 可重建任意历史状态 |
| 存储空间 | 较小（仅存当前值） | 较大（事件持续追加） |
实践建议：事件溯源通常与CQRS（命令查询职责分离）配合使用。写模型只追加事件，读模型从事件流投影出查询视图。
4.3 事件与消息的区别
在分布式系统和消息中间件（如Kafka）中，“事件”和“消息”经常被混用，但它们在DDD和架构层面有本质区别。
| 对比维度 | 领域事件（Domain Event） | 消息（Message） |
|---|---|---|
| 定义层次 | 业务语义层（DDD战术模式） | 技术传输层（中间件概念） |
| 核心关注点 | 发生了什么事实？业务含义是什么？ | 如何传输？如何保证可靠性？ |
| 数据结构 | 包含业务属性、时间戳、版本、聚合ID | 包含Key、Value、Headers、Partition |
| 消费者语义 | 订阅者根据事件做出业务反应 | 消费者按Topic/Partition拉取处理 |
| 持久化策略 | 事件溯源：追加存储，不可变 | 日志存储：可配置保留策略（TTL/大小） |
| 重放能力 | 核心特性：通过重放重建状态 | 支持：通过重置Offset重新消费 |
常见误区：不要将Kafka中的每条记录都视为领域事件。只有那些具有业务含义、领域专家关心的“事实”才应建模为领域事件。技术日志、心跳、缓存失效等属于消息，不应进入领域事件流。
4.4 领域事件在Kafka中的映射
在Kafka消息驱动架构中，领域事件通常映射为Kafka Topic中的一条记录。但映射不是简单的1:1复制，需要遵循以下原则：
- Topic命名：使用业务含义命名，如
order.events、payment.events。 - 事件序列化：使用Avro、Protobuf或JSON Schema，保证事件结构的演进兼容性。
- 分区键：使用聚合根ID作为分区键，保证同一聚合的事件顺序性。
- 幂等性：消费者需实现幂等处理，因为Kafka可能重复投递消息。
4.5 实践要点总结
- 事件命名：使用过去时态动词，如
OrderConfirmed、PaymentFailed。 - 事件粒度：一个领域事件对应一个聚合的一次状态变更，避免合并多个业务事实。
- 事件版本：为事件结构引入版本号（如
v1、v2），支持Schema演进。 - 消息可靠性：Kafka生产者使用
acks=all+ 幂等生产者，消费者手动提交Offset。 - 事件去重：消费者侧维护已处理事件ID集合，实现幂等消费。
架构决策提示：如果系统需要完整的审计追溯、时间旅行查询或复杂事件驱动流程，优先考虑事件溯源。如果仅需服务间异步解耦，使用Kafka消息传递领域事件即可，无需引入完整的事件溯源存储。