问题描述 📔 Data change VS business event 在笔者就职的部门的现有系统中，一个常见的模式是让下游直接消费“解析后的MySQL 表的 binlog”——也就是数据库行级变更的 before / after 镜像——并把它当成“业务消息”来使用。 这种做法在原型阶段确实省事：binlog 已经包含了字段差异，无需额外开发，任何一次 UPDATE、DELETE 都能自动生成“事件”。 然而，把数据变更（Data change）当成业务事件（Business event）来驱动整个链路，本质上是用“存储层实现细节”替代“业务流程核心语义”，不仅丢失了上下文信息（从而影响业务决策），也使得上下游之间存在了更强的耦合。从架构设计的角度看，是一种反模式，它存在语义缺失的问题，并在长期看增大了系统模块间的耦合程度，容易造成隐患。通过下表，我们可以对比数据变更和业务事件的区别： 维度