📚 课程目录第1章模块划分的核心原则

第1章模块划分核心原则：高内聚、低耦合、单一职责、接口隔离

模块划分的四个核心原则是软件架构的基石，决定了系统的可维护性、可测试性和演化能力。它们不是孤立的口号，而是指导接口契约设计、依赖方向控制和边界划定的一系列具体规则。本章从架构师视角拆解每个原则的本质，并结合分层、数据流、信任链路等维度分析其落地方式与权衡点。

原则	核心描述	对模块边界的影响	对接口契约的要求
高内聚	模块内部元素在功能和数据上紧密关联，共同完成单一职责	边界内所有元素应属于同一逻辑领域	只暴露与职责直接相关的操作
低耦合	模块间依赖最小化，对外部变化不敏感	通过接口而非实现细节交互	契约稳定，不暴露内部状态
单一职责	一个模块只承担一个明确的业务职能	边界由业务能力而非技术实现切割	接口功能聚合度高，无混杂
接口隔离	不为依赖方提供不需要的接口，按场景切分	每个依赖方拥有专属接口子集	细粒度、按需设计，避免大而全

架构视角：四个原则共同指向同一个目标——让模块成为可独立理解、替换、测试和部署的单元。高内聚和单一职责定义“模块内部做什么”，低耦合和接口隔离定义“模块之间怎么连”。

模块划分的第一步是确定系统边界。实践中通常采用分层架构：每一层内聚于一个抽象层次（如应用、业务、数据），层间通过接口契约单向依赖。这种结构强制了信任链路——上层信任下层提供的接口能力，下层不对上层做任何假设。依赖方向一旦逆转，就会产生循环依赖，破坏模块独立性。

分层	典型职责	依赖方向	接口隔离示例
应用层	用户交互、流程编排	→ 业务层	只提供用例级服务方法
业务层	领域逻辑、规则引擎	→ 数据层	按领域聚合根设计仓储接口
数据层	持久化、缓存、外部集成	→ 基础设施	屏蔽具体数据库细节
基础设施层	消息队列、网络、三方SDK	无向上依赖	以适配器模式暴露接口

关键风险：如果接口契约中包含了不属于本层职责的方法（例如业务层接口直接暴露数据库查询），就会破坏单一职责；如果下层接口不断膨胀、包含多个场景的杂合操作，则违背接口隔离原则。这类“接口腐化”是模块退化的前兆。

接口契约不仅定义方法签名，还隐式描述了数据流方向和控制权的转移。在以低耦合为目标的架构中：

权衡点：过度追求高内聚可能导致模块过大、难以复用；接口隔离过细会增加接口数量和维护成本。实际中需根据业务变化频率和团队规模平衡。
落地步骤：
- 第一步：识别业务子域，用单一职责划分第一层边界。
- 第二步：定义每个模块对外暴露的接口契约，确保接口粒度符合隔离原则。
- 第三步：强制依赖方向，通过依赖注入或构建系统（如 CMake 目标依赖）阻断反向引用。
- 第四步：为每个接口契约编写验收测试，保证契约的稳定性。
验收标准：
- 每个模块的单元测试不需要启动其他模块。
- 更换某一模块的实现（如从 MySQL 换为 PostgreSQL）时，仅需修改该模块内部代码，接口契约不变。
- 接口契约文档自动生成，且不包含任何未使用的方法。

实践要点：在项目初期就固化模块边界和依赖方向，比后期重构代价低一个数量级。接口契约的评审应作为架构决策关键环节，拒绝“先写代码后补契约”的惯性。

契约层 ◆ 高内聚：每层内部职责聚焦 ◆ 低耦合：层间仅通过接口通信 ◆ 单一职责：每个模块只做一件事 ◆ 接口隔离：按场景设计最小接口

模块划分的实践本质是通过接口契约约束依赖方向，在变化中维持系统的结构性秩序。四个原则是检查表，而非教条——每一处设计取舍都应在团队内显式讨论并记录理由。

第1章 模块划分核心原则：高内聚、低耦合、单一职责、接口隔离