非Event Sourcing场景下跨微服务触发Projection的技术疑问

1. 关于传递内容：优先选择细粒度领域事件 #

即使不使用Event Sourcing，也不建议发送ProductUpdatedEvent这类粗粒度的全量更新事件，而是应该发送细粒度的、带有业务语义的领域事件（比如ProductNameChangedEvent、ProductShipmentReceivedEvent）。原因如下：

• 细粒度事件能精准反映业务变化的本质，订阅方的Projection可以只处理自己关心的字段更新，不用解析全量数据判断变化点，减少不必要的计算和复杂度。
• 符合DDD领域事件的设计原则：领域事件是业务行为的结果，而非单纯的数据变更通知。比如“产品名称修改”是一个明确的业务动作，对应的事件能让其他微服务清晰感知到业务层面的变化，而非模糊的“产品更新”。
• 如果你担心没有Event Store无法记录这些事件，可以在聚合根完成业务逻辑更新时，直接在代码里生成对应的细粒度事件，再将其转换为集成事件对外发送，无需持久化到Event Store（学习阶段若需要追溯，可临时存在数据库，但并非必须）。

2. 关于传递形式与渠道：用集成事件作为跨服务通知的标准形式 #

首先纠正你的概念误区：集成事件并非仅适用于“业务类事件”，它的核心作用是实现微服务之间的松耦合通信，只要是需要跨服务传递的状态变更通知（不管是业务操作完成，还是数据更新触发的业务状态变化），都应该用集成事件的形式发送。

具体来说：

• 当聚合根更新完成后，把生成的细粒度领域事件包装成集成事件，通过消息中间件（如Kafka、RabbitMQ）发送出去。
• 其他微服务的Projection作为订阅者，监听对应的集成事件，收到后更新自己的读模型。
• 要注意集成事件必须带有业务语义，避免发送类似“ProductDatabaseUpdated”这种纯技术层面的通知，而是保持和领域事件一致的业务含义，这样订阅方无需依赖你的数据结构细节，只需要理解业务变化即可。

内容的提问来源于stack exchange，提问作者Yamin Nather