第1章：模块划分核心原则——高内聚低耦合、单一职责、信息隐藏
1.1 为什么需要模块划分原则
在大型软件系统中，模块划分是决定系统可维护性、可扩展性和治理成本的第一杠杆。没有明确原则的划分会导致：
- 依赖地狱：模块间循环引用、跨层调用、隐式耦合。
- 边界模糊：职责重叠，修改一个模块引起连锁变更。
- 信任链断裂：缺乏信息隐藏，内部状态被外部直接修改。
本章从三个经典原则出发，建立模块划分的底层语义，为后续分层、接口设计、依赖治理奠定逻辑基础。
1.2 三大原则精解
| 原则 | 核心思想 | 度量指标 | 典型反例 |
|---|---|---|---|
| 高内聚 | 模块内部元素紧密关联，共同完成单一职责 | 内聚度（功能内聚 > 顺序内聚 > 通信内聚 > 偶然内聚） | 一个模块同时处理订单、支付、库存 |
| 低耦合 | 模块间依赖尽可能少、弱、显式 | 耦合度（数据耦合 < 标记耦合 < 控制耦合 < 外部耦合 < 内容耦合） | 模块A直接读写模块B的内部全局变量 |
| 单一职责（SRP） | 一个模块只对一类角色（Actor）负责 | 职责数量、变更原因数 | 同一个类既负责报表生成又负责数据库连接 |
| 信息隐藏 | 模块内部实现细节对外部不可见，通过接口通信 | 公开API数量与内部状态暴露程度 | 暴露内部 List 引用，允许外部直接 .add() |
实战洞察： 三原则并非独立，而是互为支撑。高内聚是低耦合的前提，单一职责是高内聚的实现方式，信息隐藏是低耦合的保障机制。
1.3 原则如何塑造架构方案
边界确定
单一职责帮助识别“变化轴”（Axis of Change）。每个轴形成一道模块边界。例如：订单模块只对订单流程变化负责；支付模块只对网关策略变化负责。边界内部高内聚，边界之间低耦合。
分层与组件职责
- 分层：遵循信息隐藏原则，上层只依赖下层的接口，下层不感知上层。典型层次：表现层 → 应用层 → 领域层 → 基础设施层。
- 组件职责：每个层内的组件进一步按单一职责拆分。例如领域层拆分为“订单聚合”、“支付策略”、“库存对象”等独立组件。
数据流/控制流/信任链路
- 数据流：高内聚确保数据流转不经过无关模块；低耦合避免数据流被隐式拦截或篡改。
- 控制流：信息隐藏强制控制流只能通过公开接口传递，禁止外部直接调用内部方法。
- 信任链路：模块间通过契约（接口、事件、消息）建立信任，内部变更不影响外部契约。
1.4 选型权衡与风险点
| 场景 | 原则冲突 | 典型风险 | 应对策略 |
|---|---|---|---|
| 性能优化 | 低耦合 vs 信息隐藏（需暴露热点数据） | 过早暴露内部状态，导致耦合飙升 | 使用DTO、只读接口、缓存层隔离 |
| 微服务拆分 | 单一职责 vs 运维成本（拆分过细） | 服务间远程调用替代进程内调用，延迟剧增 | 按业务能力聚合，保留高内聚的粗粒度服务 |
| 遗留系统重构 | 高内聚 vs 现有依赖（大泥球） | 强行拆分解偶导致回归 | 绞杀者模式 + 防腐层，逐步收敛内聚度 |
常见陷阱： 盲目追求“极致低耦合”可能产生大量间接层（工厂、代理、适配器），反而增加认知负担。耦合度目标是“适应当前演化速率”，而非最小值。
1.5 落地步骤与验收标准
落地步骤（适用于新建系统或模块重构）
- 识别变化源：列出所有可能变化的业务需求或技术替换点。
- 按单一职责分组：每个变化源对应一个模块，确保模块内的原因唯一。
- 定义接口契约：使用信息隐藏原则，只暴露最少必要API。
- 检查内聚度：验证模块内元素是否协作完成单一目标；删除无关功能。
- 测量耦合度：统计模块间 import / call / 数据共享频次；目标每对模块 ≤2 条显式依赖。
- 持续治理：通过架构守护测试（ArchTest）自动化检测原则违反。
验收标准
- 可测试性：每个模块可独立单元测试，不需要起其他模块上下文。
- 变更影响度：修改一个模块内部逻辑时，影响模块数量不超过2个（不含直接依赖的调用方）。
- 接口稳定性：模块公开API变更频率 ≤ 内部实现变更频率的 1/5。
1.6 模块划分核心原则体系内联视图
下图展示三个原则如何共同作用于模块边界、分层与组件职责，形成可治理的架构骨架。