GORM的Transaction应仅限本地聚合根操作，跨聚合需拆分为独立事务+领域事件；禁止在事务内调用HTTP/MQ/RPC，AfterCommit仅适用于幂等轻量通知，领域事件须由聚合根内部触发、经消息通道分发并配合唯一ID与状态表实现去重重试。
事务边界卡在GORM的Transaction里出不来
很多人一写复杂业务就直接套db.Transaction()，把整个用例逻辑包进去。结果是：订单创建、库存扣减、优惠券核销、物流单生成全塞在一个事务里。一旦物流接口超时或下游失败，前面所有DB操作全回滚——但库存其实已经扣了，只是没来得及发消息通知其他系统，最终导致状态不一致。
根本问题不是GORM不支持拆事务，而是把“数据库事务”和“业务一致性”混为一谈。DDD里明确区分：数据库事务只管本地ACID，跨聚合/跨限界上下文的一致性靠领域事件+最终一致性保障。
- 别在
Transaction里调外部HTTP、MQ、RPC，这些操作天然不可回滚 - 一个事务只做一件事：更新当前聚合根及其内聚对象（比如
Order和它的OrderItem） - 涉及多个聚合的操作（如扣库存、发通知），必须拆成独立事务+事件发布
AfterCommit钩子不是万能的，它只解决“本事务成功后发事件”
GORM 1.23+ 提供了AfterCommit回调，看起来很适合发领域事件。但它有硬伤：只对当前DB会话生效，且无法感知事务是否真被提交（比如主库提交了但从库延迟同步，事件消费端读不到最新数据）。
更现实的问题是：你没法在AfterCommit里安全地调用另一个聚合的仓储方法——因为那个聚合可能属于不同限界上下文，其仓储实现可能依赖完全不同的数据库或缓存策略。
-
AfterCommit适合轻量级、幂等、无副作用的通知（如记录日志、触发监控告警） - 真正要驱动业务协作的领域事件（如
OrderPlacedEvent），必须由应用层显式发布，并走独立的消息通道（Kafka/RabbitMQ） - 如果非要用GORM钩子，务必配合
event_id+ 状态表做去重，避免重复投递
领域事件怎么从GORM模型里“长出来”
很多人把事件当DTO用，在Service里new一个OrderPlacedEvent{OrderID: xxx}然后塞进MQ。这违背DDD原则：领域事件必须是领域行为的自然产物，不能由基础设施层凭空构造。
正确做法是在聚合根内部定义事件触发点。比如Order实体的Confirm()方法执行完状态变更后，调用addDomainEvent(&OrderConfirmedEvent{...})，这个addDomainEvent是聚合根基类提供的能力，事件暂存在内存列表里，等应用层调用orderRepository.Save()时统一取出并交由事件总线分发。
- 事件结构体必须放在领域层，字段命名用业务语言（如
ShippingAddress而不是shipping_addr） - 不要在事件里放敏感数据（如用户手机号），只传必要ID和摘要信息
- GORM模型（
OrderModel）和领域模型（Order）必须分离，前者只负责映射，后者才承载行为和事件
跨数据库事务失败后，怎么让领域事件“重试但不重复”
典型场景：订单服务用MySQL，库存服务用PostgreSQL。订单事务提交后发OrderPlacedEvent，库存服务消费失败。重试机制若不加控制，会导致同一订单被反复扣减库存。
关键不在GORM，而在事件设计本身。每个领域事件必须带唯一eventId（UUID），且消费端要维护processed_events表记录已处理ID。GORM可以帮你建这个表，但不能替你决定什么时候查、什么时候插。
- 不要依赖GORM的
FirstOrCreate做事件去重——它只对单次请求有效，集群下无效 - 推荐用
INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或INSERT IGNORE（MySQL）原子插入事件ID - 重试间隔建议指数退避，首次1s，最多重试5次，之后转入死信队列人工干预
最常被忽略的一点：领域事件不是用来替代事务的，而是用来承认“事务只能管住自己那一亩三分地”。GORM再强大，也管不了第三方API响应时间、网络抖动、下游服务重启。接受这个事实，才能把事件真正用对地方。
