4. 读写模型边界划分原则

在 CQRS 架构中，读写模型的边界划分是决定系统复杂度与灵活性的关键决策。错误的边界会导致命令与查询相互耦合、数据不一致或过度工程化。本章从三个核心维度展开：为什么需要分离、粒度如何控制、Bounded Context 与 CQRS 的关系。

4.1 为什么需要分离读写模型

传统 CRUD 架构将同一实体同时用于命令（写）和查询（读），导致以下问题：

分离后的收益：

• 独立优化：写模型可使用规范化存储（如 PostgreSQL），读模型可使用反规范化视图（如 Elasticsearch、Redis）。
• 独立安全：写模型校验权限与业务规则，读模型只做数据投影，减少攻击面。
• 独立演化：读模型可随时新增投影字段而不影响写模型，反之亦然。

4.2 边界划分的粒度

读写模型的边界并非“一刀切”全部分离，而是根据业务场景选择合适粒度。以下是三种常见粒度模式：

在 Go 代码中，中粒度分离的典型结构：

// 写模型 —— 领域聚合
type Order struct {
    ID        OrderID
    Items     []OrderItem
    Status    OrderStatus
    Version   int
}

func (o *Order) Submit() error {
    // 校验业务规则
    if o.Status != OrderStatusDraft {
        return ErrInvalidStatus
    }
    o.Status = OrderStatusSubmitted
    return nil
}

// 读模型 —— 查询投影
type OrderListView struct {
    OrderID     string
    CustomerName string
    ItemCount   int
    TotalAmount float64
    Status      string
    CreatedAt   time.Time
}

4.3 上下文边界（Bounded Context）与 CQRS 的关系

Bounded Context 是 DDD 中划分领域边界的核心模式，CQRS 是每个 Context 内部实现读写分离的架构模式。两者关系如下：

• 每个 Bounded Context 可独立决定是否使用 CQRS：核心域（如订单、支付）适合 CQRS，支撑子域（如通知、日志）可能不需要。
• CQRS 的读写边界不应跨越 Bounded Context：读模型只能投影当前 Context 内的事件，跨 Context 的数据应通过上下文映射（Context Map）或事件总线同步。
• Bounded Context 是 CQRS 的天然部署单元：每个 Context 可拥有独立的读库、写库和事件存储。

下图展示了一个电商系统中 Bounded Context 与 CQRS 的典型关系：

4.4 边界划分决策矩阵

在实际项目中，可通过以下矩阵快速判断是否需要在某个 Bounded Context 内分离读写模型：

4.5 边界划分的常见陷阱

1. 过度分离：每个聚合都拆成读写模型，导致代码量翻倍、维护成本激增。建议只对核心域和支撑域中查询复杂的部分使用 CQRS。
2. 边界泄漏：读模型直接引用写模型的内部结构（如私有字段），导致两者耦合。应通过事件或 DTO 解耦。
3. 同步陷阱：在同一个事务中同时更新写库和读库，违背 CQRS 的最终一致性原则。应使用事件驱动异步同步。
4. 忽略上下文映射：跨 Bounded Context 的读模型未通过事件总线同步，而是直接查询源 Context 的数据库，导致部署耦合。