4. 报表领域边界定义：如何划分报表上下文、与订单/用户/财务等模块的边界

在微服务架构中，报表模块往往是最容易产生“边界模糊”的模块。许多团队将报表视为一个“万能查询层”，直接跨库读取订单、用户、财务等领域的表，导致耦合严重、缓存失效、查询性能不可控。本章从领域驱动设计（DDD）的限界上下文（Bounded Context）出发，明确报表模块的职责边界，并给出与订单、用户、财务等核心模块的协作契约。

4.1 报表模块的限界上下文定位

报表模块不是一个“数据源”，而是一个数据消费与聚合层。它的核心职责是：从各个领域模块获取已发布的事实数据，进行多维聚合、存储快照，并提供查询与导出能力。报表模块不拥有原始业务数据的写入权，也不应直接访问其他模块的数据库。

4.2 报表上下文与订单上下文的边界

订单上下文是报表模块最重要的数据来源之一。边界划分的核心在于：报表模块只关心“已完成的订单事实”，不关心订单的中间状态变更。

• 订单模块负责：订单创建、支付、发货、取消等完整生命周期管理，发布 OrderCompleted、OrderRefunded 等领域事件。
• 报表模块负责：订阅 OrderCompleted 事件，将订单金额、商品明细、用户ID、完成时间等字段写入报表宽表（如 order_daily_snapshot）。
• 禁止行为：报表模块直接查询订单的 order_status 字段来判断是否计入统计；必须依赖事件中的“已完成”标记。

// 报表模块订阅订单完成事件
type OrderCompletedEvent struct {
    OrderID   string
    UserID    string
    TotalAmount  float64
    ProductIDs   []string
    CompletedAt  time.Time
}

func (s *ReportService) HandleOrderCompleted(ctx context.Context, evt OrderCompletedEvent) error {
    snapshot := &OrderDailySnapshot{
        Date:        evt.CompletedAt.Format("2006-01-02"),
        OrderCount:  1,
        TotalAmount: evt.TotalAmount,
        ProductIDs:  evt.ProductIDs,
    }
    return s.repo.UpsertDailySnapshot(ctx, snapshot)
}

4.3 报表上下文与用户上下文的边界

用户上下文提供报表模块所需的“维度属性”，例如用户等级、地域、注册渠道等。边界划分的核心在于：报表模块不存储用户全量信息，只缓存必要的维度标签。

• 用户模块负责：维护用户基础信息、等级、标签，发布 UserProfileChanged 事件。
• 报表模块负责：在报表宽表中冗余存储用户ID、用户等级、地域等维度字段（从事件中提取），避免每次查询都调用用户RPC。
• 数据一致性：用户等级变更后，报表模块通过事件更新历史快照中的用户等级字段（异步批量更新）。

4.4 报表上下文与财务上下文的边界

财务上下文对数据准确性要求极高，报表模块必须严格遵循“只读引用”原则。边界划分的核心在于：报表模块不参与任何财务计算，只展示财务模块提供的已结算数据。

// 报表模块调用财务RPC获取发票数据（非直接查库）
type FinanceRPCClient interface {
    QueryInvoices(ctx context.Context, req *InvoiceQueryReq) (*InvoiceQueryResp, error)
}

func (s *ReportService) GetInvoiceReport(ctx context.Context, date string) (*InvoiceReport, error) {
    resp, err := s.financeClient.QueryInvoices(ctx, &InvoiceQueryReq{
        StartDate: date,
        EndDate:   date,
    })
    if err != nil {
        return nil, fmt.Errorf("call finance rpc: %w", err)
    }
    // 聚合RPC返回的数据
    return s.aggregateInvoice(resp.Invoices), nil
}

4.5 边界划分的SVG架构图

下图展示了报表模块与订单、用户、财务三个上下文之间的边界与数据流向。注意所有数据获取均通过事件或RPC，不存在跨库直连。

4.6 边界划分的Go代码组织

在Go项目中，报表模块的包结构应体现清晰的边界。每个外部模块的数据获取封装在独立的 adapter 层，避免领域逻辑与外部依赖耦合。

report/
├── domain/                  # 报表领域核心
│   ├── entity/              # 报表聚合实体
│   │   └── daily_snapshot.go
│   ├── repository/          # 仓储接口
│   │   └── snapshot_repo.go
│   └── service/             # 报表领域服务
│       └── report_service.go
├── adapter/                 # 适配层（边界实现）
│   ├── event/               # 事件订阅适配器
│   │   ├── order_handler.go     # 订阅订单事件
│   │   ├── user_handler.go      # 订阅用户事件
│   │   └── finance_handler.go   # 订阅财务事件
│   ├── rpc/                 # RPC调用适配器
│   │   └── finance_client.go    # 财务RPC客户端
│   └── repo/                # 仓储实现
│       └── mysql_snapshot_repo.go
├── api/                     # 对外API
│   ├── http/                # HTTP接口
│   └── grpc/                # gRPC接口
└── cmd/                     # 启动入口
    └── main.go

4.7 边界划分的常见反模式

以下反模式在实际项目中频繁出现，会导致报表模块与周边模块的边界模糊，应主动规避。

4.8 边界划分的验收标准

在代码评审或架构评审中，可以使用以下标准快速判断报表模块的边界是否合理：

1. 数据流向检查：报表模块的所有数据是否都来自事件订阅或RPC接口？是否存在直接访问其他模块数据库的代码？
2. 写入权限检查：报表模块是否只写入自己的表（report_* 前缀）？是否修改过订单、用户、财务模块的表？
3. 业务规则检查：报表模块中是否存在 if order.Status == "paid" 这样的业务判断？这些判断应属于订单模块。
4. 依赖方向检查：报表模块是否依赖其他模块的领域模型？应只依赖事件DTO或RPC proto定义。