2. 识别业务场景中的模块化需求
在决定模块化与插件化的具体方案之前，必须对业务场景进行系统性诊断。盲目套用“微模块”或“大单体”都会导致架构失衡。本章从四个核心维度——拆分粒度、业务复杂度、团队规模、演进趋势——建立评估框架，帮助团队在模块边界、分层策略、组件职责等关键设计上达成共识。
2.1 系统拆分粒度：从微观到宏观的权衡
拆分粒度直接影响模块内聚性、通信开销和运维复杂度。常见的粒度等级如下表所示，选型时需结合业务场景的耦合特征与团队吞吐能力。
| 粒度等级 | 典型规模 | 模块职责 | 通信成本 | 适用场景 |
|---|---|---|---|---|
| 函数级 | 1～5 函数 | 单个算法/工具 | 极低（进程内调用） | 纯工具库、无状态计算 |
| 类/组件级 | 5～30 类 | 单一业务能力 | 低（接口引用） | 业务逻辑集中、变更频率低 |
| 服务级 | 1～10 服务 | 完整业务域 | 中（RPC/消息队列） | 复杂业务、跨团队协作 |
| 子系统级 | 10+ 服务 | 独立业务生态 | 高（API网关+异步队列） | 多部门大型项目、需要独立部署 |
风险点：拆分过细（例如所有方法都独立成插件）会导致接口爆炸，模块间依赖关系难以管理，团队协作时频繁等待接口对齐。粗粒度拆分（例如将10个功能打包成1个模块）则容易产生“上帝模块”，破坏内聚性。
2.2 业务复杂度评估：模块边界与数据流
业务复杂度可从领域内聚度和跨模块数据依赖两个维度量化。高内聚、低耦合的模块可优先独立；反之，数据强关联的模块应合并或建立标准化数据通道。
模块边界判定矩阵
使用以下四个问题快速评估每个候选模块的边界合理性：
- 变更原因：该模块的修改是否只来自单一业务需求？
- 数据所有权：模块是否拥有并管理自己的核心数据？
- 控制流方向：外部调用是否只能通过定义的接口，而非直接操作内部状态？
- 信任链路：模块间是否需要跨信任域（安全边界）？若需要，则插件化隔离更强。
满足3项以上的候选模块，可初步作为独立拆分单元。
数据流与控制流分析示例
以下是一个电商订单模块与支付模块之间的典型数据流与控制流片段，用于判断是否需要插件化解耦：
数据流：
订单模块 → 支付模块：{ orderId, amount, currency }
支付模块 → 订单模块：{ paymentId, status, transactionTime }
控制流：
订单模块调用 PayService.process(orderId)
PayService.process 内部检查余额、调用三方网关
若超时或失败，支付模块回滚本地状态并返回错误码
信任链路等级：高（共享支付凭证）
建议：强内聚，不可插件化；而第三方支付渠道可接入插件
关键原则：当模块间的数据流涉及业务核心状态变更时，信任链路必须显式声明（如签名、加密、审计日志），此时模块边界应尽可能小，避免信任扩散。
2.3 团队规模影响：组织架构决定模块粒度
根据康威定律，系统结构最终会复制组织的沟通结构。团队规模与模块拆分粒度的推荐对应关系：
| 团队规模 | 建议拆分方式 | 组件职责分配 |
|---|---|---|
| 1～5 人 | 单模块 + 内部子包 | 每人维护 1～2 个子包，代码评审把关边界 |
| 6～15 人 | 2～4 个中间粒度模块 | 每个团队负责一个模块，模块间通过 RPC 或事件通信 |
| 15～50 人 | 服务级拆分 + 插件网关 | 每个服务由独立小组维护，核心公共能力通过插件注册 |
| 50 人以上 | 子系统 + 插件市场 | 每个子系统拥有独立 CI/CD，插件生态由专门的治理团队管理 |
落地步骤建议：从当前团队规模出发，先以微服务或模块方式运行 1～2 个迭代，再根据实际协作瓶颈调整粒度。不要一次性定义终极方案。
2.4 演进趋势分析：为未来扩展预留弹性
模块化系统面临的最大风险是“写死”当前拆分策略，导致未来新业务无法接入。以下四个演进趋势指标可帮助判断是否需要插件化：
- 变更频率异质性：某些模块可能每月发版 5 次，而其他模块一年发版 1 次。高频变动模块应独立为插件，避免全量部署。
- 第三方依赖风险：如果某模块依赖外部 SDK 且升级频繁（如支付渠道、物流 API），应考虑插件化隔离升级影响。
- 功能定制化需求：不同客户需要不同功能组合时，插件化可避免每客户一套代码分支。
- 合规与安全边界：金融、医疗等场景下，不同模块的数据安全等级不同，插件化可提供独立的信任域。
2.5 选型权衡与验收标准
核心权衡：模块化不是越细越好，也不是越粗越好。细粒度带来灵活性和隔离性，但增加了集成测试和部署难度。粗粒度降低通信成本，但提高了变更风险。
本章评估完成后，团队应能回答以下验收问题：
- 模块边界是否清晰？每个模块的职责描述不超过两句话，且不重复。
- 数据流是否单向？模块间不应出现循环依赖。
- 控制流是否可审计？关键链路的调用链能够完整追踪。
- 信任链路是否显式？跨安全域的操作必须经过接口校验和授权。
- 未来半年内预期变更是否被现有拆分覆盖？若存在高概率新增功能无法融入，则应推迟拆分或预留插件点。