3. 微服务拆分原则与策略：领域驱动设计(DDD)在报表拆分中的应用、服务粒度划分
报表导出服务从单体架构向微服务架构演进时，最核心的挑战并非技术选型，而是服务边界的合理划定。错误的拆分会导致跨服务调用泛滥、数据一致性难以保障、团队协作效率下降。本节将引入领域驱动设计（DDD）作为方法论武器，结合报表导出业务场景，讲解如何通过战略设计与战术设计指导服务粒度划分。
3.1 为什么报表拆分需要 DDD？
传统分层架构（Controller → Service → DAO）在单体应用时代足够直观，但当业务逻辑复杂到一定程度后，会出现以下问题：
- 业务逻辑散落：报表的查询条件拼接、权限过滤、格式转换等逻辑分散在多个 Service 中，难以复用。
- 数据库耦合：多个模块直接访问同一张报表配置表，修改表结构时牵一发而动全身。
- 服务边界模糊：团队 A 负责的“报表元数据管理”与团队 B 负责的“报表数据查询”之间缺乏清晰的契约。
3.2 战略设计：识别限界上下文
战略设计阶段的目标是从业务事件出发，识别出独立的限界上下文。每个限界上下文对应一个潜在的微服务或模块。以报表导出业务为例，我们通过事件风暴（Event Storming）梳理出以下核心领域事件：
| 领域事件 | 所属上下文 | 说明 |
|---|---|---|
| 报表模板已创建 | 报表元数据管理 | 定义报表名称、数据源、查询 SQL、列映射 |
| 导出任务已提交 | 导出任务调度 | 接收用户请求，生成任务记录，进入队列 |
| 数据查询已完成 | 报表数据查询 | 根据模板配置执行 SQL，返回原始数据集 |
| 文件已生成 | 文件生成与存储 | 将数据集转换为 Excel/CSV/PDF，上传至对象存储 |
| 导出结果已通知 | 通知与分发 | 通过邮件/站内信/Webhook 推送下载链接 |
基于上述事件，我们可以初步划分出 4 个限界上下文：
- 报表元数据上下文：管理模板、数据源连接、查询配置。
- 导出任务上下文：接收导出请求、调度执行、跟踪状态。
- 数据查询上下文：执行查询、处理分页、应用权限过滤。
- 文件处理上下文：格式转换、文件存储、过期清理。
3.3 战略设计成果：上下文映射图
下图展示了报表导出业务中 4 个限界上下文之间的协作关系。箭头方向表示依赖或调用方向，标注了交互模式（如 RPC 调用、异步消息）。
3.4 战术设计：聚合与实体划分
战略设计确定了“大边界”，战术设计则负责在每个限界上下文内部细化聚合（Aggregate）、实体（Entity）、值对象（Value Object）。聚合是数据一致性的最小单元，一个聚合内的修改必须在一次事务中完成。
以导出任务上下文为例，其内部聚合设计如下：
| 聚合名称 | 根实体 | 包含实体/值对象 | 一致性要求 |
|---|---|---|---|
| 导出任务聚合 | ExportTask | TaskParameter（值对象）、TaskStatus（枚举）、TaskResult（值对象） | 任务状态变更必须与结果记录同时持久化 |
| 任务队列聚合 | TaskQueue | QueueItem（实体）、QueueConfig（值对象） | 队列出队操作必须保证幂等性 |
3.5 服务粒度划分原则
基于 DDD 的限界上下文和聚合设计，我们可以推导出微服务的粒度划分原则。以下 4 条原则在报表拆分实践中被证明最为有效：
- 按业务能力拆分：每个限界上下文对应一个独立的微服务。例如“报表元数据服务”、“导出任务服务”、“数据查询服务”、“文件处理服务”。
- 按聚合边界拆分：如果一个限界上下文内部包含多个聚合，且这些聚合的变更频率差异较大，可以考虑进一步拆分。例如“导出任务服务”与“任务队列服务”可以独立部署。
- 按数据一致性要求拆分：需要强一致性的操作尽量放在同一个服务内。例如“提交导出任务”与“更新任务状态”属于同一个聚合，不应拆到两个服务。
- 按团队组织拆分（康威定律）：如果团队 A 负责报表配置管理，团队 B 负责导出执行，那么即使业务上紧密相关，也建议拆分为两个服务，通过 gRPC 契约解耦。
3.6 报表拆分实战：服务粒度决策矩阵
在实际项目中，我们经常需要在“粗粒度”与“细粒度”之间权衡。以下矩阵可以帮助团队做出决策：
| 评估维度 | 粗粒度（合并服务） | 细粒度（拆分服务） |
|---|---|---|
| 团队协作 | 适合小团队（< 5 人），减少沟通成本 | 适合大团队（> 10 人），支持独立迭代 |
| 变更频率 | 各模块变更频率相近，合并后减少部署次数 | 各模块变更频率差异大，拆分后可独立发布 |
| 数据一致性 | 需要强一致性，合并后可使用本地事务 | 可接受最终一致性，拆分后使用 Saga 或事件驱动 |
| 性能要求 | 低延迟场景，合并后减少网络开销 | 高吞吐场景，拆分后可独立扩缩容 |
| 技术栈 | 技术栈统一，合并后降低运维复杂度 | 不同模块适合不同技术栈（如数据查询用 ClickHouse，文件处理用 Go） |
3.7 战术设计成果：聚合内部结构图
下图以导出任务聚合为例，展示聚合内部实体、值对象以及与其他聚合的引用关系。注意聚合之间的引用只能通过根实体的 ID 进行，不能直接持有对象引用。
3.8 从 DDD 到 gRPC 契约
完成服务粒度划分后，下一步就是将聚合的行为暴露为 gRPC 服务接口。每个限界上下文对外提供 1-2 个 gRPC 服务，服务的方法对应聚合的公共操作。例如：
- 导出任务服务（ExportTaskService）：
SubmitExportTask、GetTaskStatus、CancelTask - 报表元数据服务（ReportMetadataService）：
GetTemplateById、ValidateParameters - 数据查询服务（DataQueryService）：
ExecuteQuery（流式返回） - 文件处理服务（FileProcessingService）：
GenerateFile、GetDownloadUrl