4. 边界定义原则：单一职责、接口隔离、依赖反转在报表模块边界划分中的应用

在报表系统的模块边界划分中，SOLID 原则中的三个核心原则——单一职责原则（SRP）、接口隔离原则（ISP）和依赖反转原则（DIP）——是指导边界定义最直接、最有效的工具。它们分别从职责内聚、契约粒度和依赖方向三个维度，确保报表模块的边界清晰、稳定且易于演进。

4.1 单一职责原则（SRP）：边界内聚的基石

单一职责原则要求一个模块只对一个角色（Actor）负责。在报表系统中，这意味着一个报表模块不应同时承担数据获取、格式渲染、权限校验和调度触发等职责。每个职责的变化原因不同，若放在同一边界内，会导致模块频繁修改、测试困难。

以下表格展示了报表系统中常见的职责混淆场景及正确的边界划分建议：

4.2 接口隔离原则（ISP）：边界契约的粒度控制

接口隔离原则强调：客户端不应被迫依赖它不使用的方法。在报表模块的边界定义中，ISP 指导我们设计细粒度、高内聚的接口，避免“胖接口”导致模块间耦合过紧。

以下是一个违反 ISP 的典型反例：

// 反例：胖接口，所有报表模块都依赖它
type ReportService interface {
    FetchData(query string) ([]Row, error)
    RenderHTML(template string, data []Row) (string, error)
    ExportPDF(html string) ([]byte, error)
    ScheduleReport(cron string, reportID string) error
    ValidatePermissions(userID string, reportID string) bool
}

上述接口迫使数据获取模块也必须了解渲染和调度方法。遵循 ISP 后，应拆分为多个独立接口：

// 遵循 ISP：每个接口只包含一个职责
type DataFetcher interface {
    FetchData(query string) ([]Row, error)
}

type ReportRenderer interface {
    RenderHTML(template string, data []Row) (string, error)
}

type PDFExporter interface {
    ExportPDF(html string) ([]byte, error)
}

type ReportScheduler interface {
    ScheduleReport(cron string, reportID string) error
}

type PermissionValidator interface {
    ValidatePermissions(userID string, reportID string) bool
}

接口隔离后的边界关系更加清晰：

• DataFetcher 只被数据源模块实现，只被报表引擎依赖。
• ReportRenderer 只被渲染模块实现，只被输出模块依赖。
• PermissionValidator 只被权限模块实现，只被调度或 API 网关依赖。

4.3 依赖反转原则（DIP）：边界依赖的方向控制

依赖反转原则指出：高层模块不应依赖低层模块，两者都应依赖抽象；抽象不应依赖细节，细节应依赖抽象。在报表系统中，DIP 确保核心业务逻辑（如报表编排、数据聚合）不直接依赖具体的数据源、文件系统或第三方库，从而保持边界的稳定性。

以下 SVG 展示了应用 DIP 前后的依赖方向对比：

4.4 三原则协同：报表模块边界划分实战

在实际的报表系统架构中，SRP、ISP 和 DIP 并非孤立使用，而是协同作用。以下是一个基于 Go 语言的报表模块边界划分示例，展示三原则如何共同推导出清晰的模块边界：

// 1. SRP 定义模块职责：每个包只做一件事
package fetcher     // 职责：数据获取
package transformer // 职责：数据转换/聚合
package renderer    // 职责：报表渲染
package scheduler   // 职责：调度执行
package exporter    // 职责：导出输出

// 2. ISP 定义边界接口：每个接口只暴露必要方法
// fetcher 包
type Fetcher interface {
    Fetch(ctx context.Context, query string) ([]Record, error)
}

// transformer 包
type Transformer interface {
    Transform(records []Record) (*DataSet, error)
}

// renderer 包
type Renderer interface {
    Render(dataSet *DataSet, template string) (string, error)
}

// 3. DIP 控制依赖方向：高层依赖抽象，低层实现抽象
// 高层：报表编排器（依赖接口，不依赖具体实现）
type ReportOrchestrator struct {
    fetcher     fetcher.Fetcher
    transformer transformer.Transformer
    renderer    renderer.Renderer
}

func (o *ReportOrchestrator) GenerateReport(ctx context.Context, query string) (string, error) {
    records, err := o.fetcher.Fetch(ctx, query)
    if err != nil {
        return "", err
    }
    dataSet, err := o.transformer.Transform(records)
    if err != nil {
        return "", err
    }
    return o.renderer.Render(dataSet, "default")
}

// 低层：具体实现（依赖抽象接口）
type MySQLFetcher struct {
    db *sql.DB
}

func (m *MySQLFetcher) Fetch(ctx context.Context, query string) ([]Record, error) {
    // 具体实现
    return nil, nil
}

4.5 边界定义原则总结

以下表格总结了 SRP、ISP 和 DIP 在报表模块边界划分中的角色与作用：