3、耦合的根源：领域层对基础设施层的直接依赖、硬编码依赖的坏味道

在领域驱动设计的实践中，领域层是系统的核心与灵魂，它承载着业务规则与逻辑。然而，当领域层直接依赖基础设施层（如数据库、外部服务、文件系统）时，这种核心地位便会被侵蚀。这种依赖是软件系统中耦合的主要根源之一，它让领域逻辑变得脆弱、难以测试且无法独立演化。

3.1 直接依赖：领域层与基础设施层的“硬连接”

当领域层中的实体或服务直接实例化一个数据库仓库或发送HTTP请求时，领域层便与基础设施层产生了“硬连接”。这种依赖关系破坏了领域层的纯净性，使得任何基础设施的变更都可能引发领域层的连锁修改。

下面的SVG图展示了这种不合理的依赖关系：领域层（核心）直接指向基础设施层，形成了单向但有害的耦合。

3.2 硬编码依赖的四种典型坏味道

硬编码依赖是直接依赖的具体表现形式，它们在代码中留下了明显的“坏味道”。识别这些坏味道是重构的第一步。下表总结了四种最常见的场景及其危害。

3.3 耦合的连锁反应：从代码到架构

领域层与基础设施层的直接依赖并非孤立问题，它会引发一系列架构层面的连锁反应，最终导致整个系统的僵化。

• 可测试性崩塌： 领域逻辑无法脱离基础设施单独测试，单元测试退化为集成测试，运行缓慢且不稳定。
• 可维护性下降： 更换数据库或消息队列时，需要修改领域层代码，增加了回归风险。
• 业务逻辑污染： 基础设施的异常处理、连接管理、序列化细节侵入领域层，使业务规则变得模糊。
• 团队协作阻塞： 领域专家与基础设施开发者的工作被强行绑定，无法并行推进。

下面的SVG图展示了这种耦合如何从代码层面扩散到整个架构，形成“雪崩效应”。

3.4 代码层面的具体表现

让我们通过一段Go代码来直观感受硬编码依赖的坏味道。以下是一个典型的反面示例：

// 领域层 —— 订单服务（反面示例：直接依赖基础设施）
package domain

import (
    "database/sql"
    "fmt"
    "net/smtp"
)

type OrderService struct {
    db *sql.DB  // 直接依赖数据库
}

func (s *OrderService) CreateOrder(order Order) error {
    // 直接操作数据库
    _, err := s.db.Exec("INSERT INTO orders ...")
    if err != nil {
        return fmt.Errorf("failed to save order: %w", err)
    }

    // 直接发送邮件
    err = smtp.SendMail("smtp.example.com:25", nil, "from@example.com",
        []string{"user@example.com"}, []byte("Order created"))
    if err != nil {
        return fmt.Errorf("failed to send email: %w", err)
    }

    return nil
}

3.5 解耦的起点：依赖倒置原则（DIP）

解决耦合问题的核心武器是依赖倒置原则（Dependency Inversion Principle, DIP）。该原则要求：

1. 高层模块不应依赖低层模块，两者都应依赖抽象。
2. 抽象不应依赖细节，细节应依赖抽象。

在DDD的语境下，这意味着领域层（高层模块）应定义接口（抽象），而基础设施层（低层模块）应实现这些接口。这样，依赖的方向就被反转了：领域层不再直接依赖基础设施，而是基础设施依赖领域层定义的接口。

下表对比了直接依赖与依赖倒置两种模式的核心差异：