DDD 领域驱动设计 经典DDD分层架构

领域驱动设计（Domain-Driven Design，DDD）是一种以业务领域为核心的软件设计方法，通过将复杂业务逻辑抽象为领域模型，帮助开发者更好地理解和实现业务需求。

DDD分层架构通常包含：用户界面层、应用层、领域层、基础设施层；

根据依赖倒置原则，高层模块不应该依赖低层模块，两者都应该依赖抽象；

在DDD中，领域层应该定义仓储接口，而基础设施层实现这些接口，这样领域层就不会直接依赖基础设施层，而是基础设施层依赖领域层；

分层架构中的依赖方向

在经典DDD分层架构中，依赖关系应遵循依赖倒置原则（DIP）：

领域层 → 定义接口

基础设施层 → 实现接口

核心规则

领域层不依赖基础设施层：领域模型和业务逻辑应保持纯净，不涉及技术实现细节（如数据库、网络等）。

基础设施层依赖领域层：通过实现领域层定义的接口（如仓储接口）来完成技术细节。

关键设计原则

（1）依赖倒置原则（DIP）

领域层定义抽象接口，基础设施层实现这些接口。

打破传统分层依赖，避免领域层被技术细节污染。

（2）单一职责原则

领域层：只关注业务规则和领域模型。

基础设施层：只关注技术实现（如数据库操作、API调用）。

（3）明确分层边界

禁止领域层直接调用基础设施（如new MySQLOrderRepository()）。

禁止基础设施层修改领域模型（如数据库ORM框架侵入领域对象）。

常见问题与解决方案

（1）领域层需要访问外部服务怎么办？

定义领域服务接口：在领域层声明依赖的外部能力。

基础设施层实现接口：例如通过HTTP客户端或消息队列实现。

（2）如何处理数据库事务？

应用层协调事务：在应用服务中通过事务管理事务边界。

领域层不感知事务：保持业务逻辑与技术解耦

5. 架构示例

高层模块不应该依赖低层模块

依赖关系图：

UI Layer
↑
Application Layer
↑
Domain Layer (定义接口)
↑
Infrastructure Layer (实现接口)

代码结构

src/
├── domain/                # 领域层
│   ├── model/             # 领域模型（实体、值对象、聚合）
│   ├── service/           # 领域服务接口
│   └── repository/        # 仓储接口（如OrderRepository）
│
└── infrastructure/        # 基础设施层
    ├── persistence/       # 仓储实现（如MySQLOrderRepository）
    ├── external/          # 外部服务调用（如AlipayPaymentService）
    └── messaging/         # 消息队列实现

总结

领域层是业务逻辑的核心，基础设施层是技术实现的细节。

通过依赖倒置和接口隔离，确保领域层不被技术细节污染。

最终目标：让业务逻辑主导系统设计，技术为业务服务，而非相反。