模块划分粒度权衡策略

模块划分的粒度——即单个模块的职能范围与内部复杂度——是架构设计中最具争议的决策之一。粒度过粗导致模块臃肿、职责模糊、依赖混乱；粒度过细则引发碎片化、协作成本激增、跨模块流程断裂。本章从团队规模、业务演进、维护代价三个维度，建立系统的权衡模型，帮助架构师在具体上下文中找到“适度粒度”。

粒度过粗 vs 过细的代价模型

团队规模匹配模型

团队规模是决定粒度上限的核心约束。依据康威定律逆推，模块粒度应匹配团队沟通拓扑。

• 小团队（2-5人）：建议每团队负责2-4个中等粒度模块。过细拆分会导致每人维护多个模块，上下文切换成本高；过粗则失去并行开发机会。
• 中型团队（6-15人）：可拆分为3-5个模块组，每组1-2个核心模块。依赖关系按分层依赖规则：上层可依赖下层，同层之间使用事件或异步通道解耦。
• 大型团队（20人以上）：必须建立模块分级体系。宏观模块（部门级）粒度较粗，内部再按子领域拆分为中粒度模块，团队内部还可进行私有模块微拆分。此时接口协议治理成为关键控制点。

演进性考量与动态调整

模块粒度不应在项目初期锁死，而应随业务阶段和系统认知深度持续调整。演进性考量包含三个信号：

1. 变更重合度：如果某个模块在一周内被多个不同目的的功能修改，说明内部职责未内聚，需要进一步拆分或重组。
2. 开发者心智负担：当新成员需要花超过2天才能理解一个模块的全部行为时，该模块可能粒度过粗，应拆解出稳定的子模块。
3. 测试比例异常：集成测试数量远多于单元测试，或模块内单元测试执行时间超过5分钟，表明模块粒度过粗，内部耦合导致测试无法局部化。

边界设计原则与数据流控制

无论粒度如何，每个模块必须满足以下边界准则：

• 职责单一且可陈述：模块名称应能用一个自然语言句子描述其核心能力，如果句子中出现“和”、“或者”、“除了”等连词，则说明职责不纯。
• 数据流入方向可控：模块对外暴露的接口应限制为查询流和命令流两种模式，避免在接口中传递内部状态引用（如共享内存对象）。
• 信任链路显式化：模块间的信任关系必须通过接口契约（如版本号、领域事件、校验签名）建立，不允许在运行时通过类型强转或隐式共享变量绕过后台信任。

落地步骤与验收标准

验收标准：

• 模块数量 ≤ 团队人数 × 1.5（上限）
• 单模块内部依赖（包间引用）数量 ≤ 10
• 跨模块调用中，80%的调用路径深度 ≤ 3（避免长链）
• 任何单个模块变更不会引起超过5个其他模块的接口适配修改
• 新成员在1小时内可理解模块边界和外部依赖

粒度权衡可视化

下图展示了粒度、团队规模与系统演进代价之间的关系，帮助团队在决策时定位当前状态。

图中的四个外围因素会推动粒度向不同方向偏移：小团队迫使粒度偏粗（减少沟通链路），业务频繁变更需要更细的拆分以隔离变化，依赖复杂度和技术栈异构则倾向于适度粒度以避免碎片化。架构师应在每次架构评审中回顾这些因素的变化，动态调整模块边界。