2. 模块化设计原则：高内聚低耦合原则、单一职责原则、接口隔离原则在模块拆分中的应用

模块拆分是企业应用架构设计的核心活动。错误的拆分会导致系统“牵一发而动全身”，正确的拆分则让团队能够独立开发、测试和部署。本节将深入剖析三条最核心的模块化设计原则，并结合实际案例说明如何在模块边界划分中落地应用。

2.1 高内聚与低耦合：模块拆分的黄金法则

高内聚指模块内部的元素（类、函数、数据）应紧密关联，共同完成一个明确的功能目标。低耦合指模块之间的依赖关系应尽可能弱，一个模块的变化对其他模块的影响最小。两者相辅相成：高内聚是低耦合的前提，低耦合是高内聚的外部表现。

2.1.1 内聚与耦合的层次对比

2.1.2 高内聚低耦合的模块结构示意

下图展示了一个符合高内聚低耦合原则的订单模块拆分方案。每个模块内部职责清晰，模块之间通过明确的接口进行数据耦合，没有共享全局状态。

2.2 单一职责原则：模块边界的精确标尺

单一职责原则（SRP）指出：一个模块应该有且仅有一个引起它变化的原因。在模块拆分中，SRP 帮助我们判断“这个模块是否应该继续拆分”。如果一个模块因为多个不同的业务需求而频繁修改，说明它承担了过多的职责。

2.2.1 职责识别与拆分方法

识别模块职责的常用方法是分析变化来源。列出所有可能触发模块修改的业务场景，如果这些场景分属不同的业务领域，就应该拆分。

2.2.2 违反 SRP 的典型场景

2.3 接口隔离原则：模块间通信的契约约束

接口隔离原则（ISP）强调：客户端不应该被迫依赖它不使用的方法。在模块拆分中，ISP 指导我们如何设计模块间的调用接口——接口应该小而专，而不是大而全。

2.3.1 胖接口 vs 瘦接口

胖接口（也称为“万能接口”）包含大量方法，调用方只需要其中一部分，却被迫依赖整个接口。当接口发生变化时，所有调用方都需要重新编译或调整，即使它们根本不使用被修改的方法。

// 违反 ISP：胖接口
public interface OrderService {
    void createOrder(Order order);
    void cancelOrder(Long orderId);
    void processPayment(Long orderId, PaymentInfo payment);
    void refundPayment(Long orderId);
    void shipOrder(Long orderId);
    void trackLogistics(Long orderId);
}

// 符合 ISP：拆分后的细粒度接口
public interface OrderCreationService {
    void createOrder(Order order);
}

public interface OrderCancellationService {
    void cancelOrder(Long orderId);
}

public interface PaymentService {
    void processPayment(Long orderId, PaymentInfo payment);
    void refundPayment(Long orderId);
}

public interface LogisticsService {
    void shipOrder(Long orderId);
    void trackLogistics(Long orderId);
}

2.3.2 接口隔离在模块边界中的应用

下图展示了 ISP 在模块接口设计中的两种模式对比。左侧的胖接口导致模块间不必要的依赖，右侧的细粒度接口让每个模块只依赖自己需要的方法。

2.4 三条原则的综合应用框架

在实际的模块拆分工作中，三条原则需要协同使用。以下框架可以帮助架构师系统性地评估和优化模块边界：

1. 职责识别：列出所有业务场景和变化来源，应用 SRP 确定每个模块的核心职责。
2. 内聚评估：检查模块内部元素是否都服务于同一职责，应用高内聚原则剔除无关功能。
3. 耦合分析：绘制模块依赖图，识别公共耦合和控制耦合，通过引入接口或事件机制降低耦合。
4. 接口设计：为每个模块设计细粒度接口，应用 ISP 确保调用方只依赖必要方法。

2.5 原则冲突时的权衡策略

三条原则在极端情况下可能产生冲突。例如，严格遵循 ISP 可能导致接口数量过多，反而增加系统复杂度。以下是常见的权衡策略：