第2章 拆分粒度的权衡：微模块、聚合模块、中台模块的适用场景
模块边界的粒度直接决定系统复杂度的分布方式。粒度过细则增加编排与通信开销；粒度过粗则丧失独立演进能力。本章从实际架构决策角度，给出三种典型粒度——微模块、聚合模块、中台模块——的定义、适用场景与取舍模型。
核心结论：没有“最优粒度”，只有与团队结构、变更频率、事务一致性要求匹配的“合适粒度”。粒度应随业务认知演进动态调整，而非一次定型。
2.1 三种粒度定义与边界特征
| 维度 | 微模块 | 聚合模块 | 中台模块 |
|---|---|---|---|
| 典型代码量 | 100～1000 行 | 3000～15000 行 | 20000～100000+ 行 |
| 职责范围 | 单一领域能力（如短信发送、图片压缩） | 一组内聚业务操作（如订单流程） | 跨业务线共享能力（如用户中心、支付） |
| 部署单元 | 独立进程/函数 | 独立服务或子域 | 独立平台级系统 |
| 依赖关系 | 无内部依赖，仅通过接口依赖外部 | 内部允许轻量协作，对外暴露统一入口 | 内部可能含子模块，提供API/SDK |
| 变更频率 | 高（按需迭代） | 中（以版本为单位） | 低（需要治理委员会评审） |
| 事务范围 | 本地事务或最终一致性 | 可接受分布式事务 | 强制最终一致性 |
| 团队规模 | 1～2人保持 | 3～9人全功能小队 | 独立产品团队+架构组 |
经验法则：一份模块边界描述文件若篇幅超过1页A4纸或包含超过7个依赖关系，说明粒度可能已经过粗；如果每次功能开发需要改动3个以上模块，说明粒度可能过细。
2.2 适用场景决策矩阵
决策取决于三个关键因子：业务变更速度、数据一致性要求、团队自治能力。
- 微模块：适用于高速迭代的独立功能（如促销规则引擎、风控因子策略）、调试和A/B测试频繁的场景。典型反面是事务强相关流程被迫拆分。
- 聚合模块：适用于中等变更节奏、业务操作之间有明确事务边界（如下单→扣库存→支付）且团队能在一个域内闭环的场景。这是大多数业务系统的默认选择。
- 中台模块：适用于跨业务线共享的基础能力（如用户认证、计费、内容管理），需要长期稳定、统一治理、多团队共用的场景。注意：中台模块一旦下沉，其变更成本极高。
高风险陷阱：不要为了“微”而微，按插件维度拆分（如按支付方式拆分支付模块）往往导致“微模块地狱”——50+微模块彼此通信，无统一监控，最终退回聚合模块。
2.3 粒度选择流程（SVG）
2.4 常见误区与风险点
- 过度标准化：中台模块试图对所有业务提供“统一模型”，导致下层接口臃肿，丧失响应力。
- 忽视一致性边界：把需要强一致性的事务拆成多个微模块，被迫引入分布式事务或Saga，反而增加复杂度。
- 团队结构与粒度错配：康威定律的体现——5人团队管理15个微模块必然导致维护真空。
- 静态分裂：一次完成全部分割，不给模块预留“成长”空间，拒绝后续合并或拆分。
2.5 落地步骤
建议在正式拆分前，先完成“模块边界描述文件”的模板。描述文件包含：模块名称、职责陈述、对外依赖、数据模型概要、事务边界、变更频率、团队归属。每个模块一页。
- 业务域事件风暴：与业务方共同梳理核心领域事件，标记热点（高频变更）和冷点（低频稳定）。
- 初步分配粒度：根据上述决策矩阵，给每个业务能力标注“候选粒度”。
- 验证一致性边界：对有分布式事务风险的模块，考虑合并或设计补偿方案。
- 编写模块边界描述文件：每个模块一页，作为架构评审文档。
- 组织架构匹配度检查：确保团队能够覆盖模块职责，没有“无人认领”的模块。
- 灰度切分：先以逻辑隔离方式运行新粒度，监控依赖链路和通信量，再决定是否物理拆分。
2.6 验收标准
- 所有模块都有清晰的职责陈述，且不同模块之间不存在职责重叠。
- 变更频率差异超过5倍的模块不会被绑定在同一部署单元内。
- 核心链路的事务一致性边界未被破坏（验收时通过压力测试与故障注入验证）。
- 团队人均维护模块数 ≤ 2（微模块场景）或 ≤ 1（聚合/中台场景）。