多限界上下文下产品对象创建与事务回滚方案咨询

当前实现的问题/不良实践 #

• 控制器职责越界：控制器既处理HTTP请求适配，又负责生成跨上下文共享ID、创建并发布多个命令，违反单一职责原则，代码耦合度高，后续维护成本上升。
• ID生成逻辑错位：将共享ID生成放在控制器（应用层），违背DDD领域驱动设计原则——领域实体的标识应由领域层控制，控制器生成ID会导致领域层失去对实体创建的控制权，后续ID生成规则变更（如切换为雪花ID）需修改控制器，不符合开闭原则。
• 缺乏分布式一致性保障：直接同步发布多个上下文的创建命令，无全局事务或补偿机制。一旦某一上下文创建失败（如数据库异常、校验不通过），已成功创建的其他上下文实体无法自动回滚，造成数据不一致。
• 同步调用容错性差：同步等待所有命令完成，若某一上下文处理缓慢，会导致HTTP请求超时，影响用户体验。

解决方案 #

1. 重构ID生成逻辑，回归领域层控制 #

将共享ID生成逻辑移至**核心限界上下文（如Catalog Context）**的领域层，通过实体工厂方法生成ID，确保领域对实体创建的控制权。示例代码：

// Catalog Context 领域层 - Product实体工厂
public static class ProductFactory
{
    public static CatalogProduct Create(string name, string description)
    {
        // 由领域层生成共享ID
        var productId = Guid.NewGuid();
        return new CatalogProduct(productId, name, description);
    }
}

控制器仅负责接收UI参数，调用应用层服务，不再处理ID生成：

[HttpPost]
public async Task<IActionResult> CreateProduct([FromBody]ProductCreateRequest request)
{
    await _productAppService.CreateAsync(request);
    return Ok();
}

2. 采用事件驱动+最终一致性（Saga模式）实现跨上下文同步 #

放弃直接同步发布多上下文命令的方式，改用核心上下文触发领域事件，其他上下文订阅事件的异步模式，结合Saga实现失败补偿：

1. 核心上下文创建实体并发布事件：在Catalog Context成功创建Product后，发布ProductCreatedDomainEvent，包含共享ID及各上下文所需的字段（如价格、库存、尺寸等）。
2. 各上下文订阅事件并创建实体：Sales、Warehouse、Shipping Context分别订阅该事件，在事件处理器中创建各自的Product实体。
3. Saga状态跟踪与补偿：引入Saga状态表，记录每个Product在各上下文的创建状态（成功/失败/待处理）。若某一上下文处理失败，触发补偿逻辑（如调用对应上下文的DeleteProductCommand），删除已成功创建的实体，保证最终一致性。

3. 引入Outbox模式提升事件可靠性 #

为避免核心上下文创建实体成功但事件未发布的情况，采用Outbox模式：

• Catalog Context在创建Product时，将ProductCreatedDomainEvent写入本地数据库的Outbox表（与Product创建在同一本地事务中）。
• 后台服务轮询Outbox表，将事件发布至消息队列，各上下文从队列消费事件。
• 消息队列自带重试机制，若消费失败自动重试，多次重试失败后触发人工干预或补偿逻辑。

优化建议 #

• 明确核心限界上下文：将Catalog Context定义为Product的核心上下文，负责产品的基础身份（ID、名称、描述），其他上下文仅维护各自关注的属性，避免属性冗余与职责混乱。
• 验证逻辑下移至领域层：各上下文的Product实体在创建时内置校验逻辑（如Warehouse Context验证库存≥0，Sales Context验证价格≥0），提前拦截无效数据，减少数据库层异常。
• 解耦控制器与多上下文逻辑：引入应用层服务（如ProductApplicationService），由应用层处理核心上下文实体创建、事件发布等逻辑，控制器仅专注于HTTP请求的接收与响应。
• 监控与告警：针对Saga状态、事件消费失败等情况，添加监控指标与告警机制，及时发现并处理数据不一致问题。

内容的提问来源于stack exchange，提问作者Kasun Jalitha