领域驱动设计（DDD）中的“核心领域逻辑与基础设施分离”原则
领域驱动设计（DDD）中的“核心领域逻辑与基础设施分离”原则
该原则是 DDD 分层架构（Clean/Hexagonal/Onion Architecture）的基石，它通过把“业务如何运作”与“技术如何实现”解耦，使领域模型能够独立于具体框架、数据库或 UI 演进。其重要性体现在：
• 保障业务知识的纯粹性与可测试性；
• 降低技术栈替换成本；
• 支撑以领域为中心的迭代与演进。
应用场景：微服务划分、CQRS/事件溯源、六边形架构、云原生迁移、遗留系统现代化等。
一、知识点框架/介绍
“核心领域逻辑与基础设施分离”是 DDD 战术设计中“分层/六边形/洋葱架构”的核心约束。它把系统划分为两个正交维度：
- 业务维度：聚焦“业务问题”——领域模型、业务规则、业务流程。
- 技术维度：聚焦“解决方案”——持久化、消息、REST、UI、第三方 API。
通过引入**端口（Port）与适配器（Adapter）**机制，领域层只依赖自己定义的端口（接口），而由基础设施层提供适配器实现。这样，领域层对 Spring、JPA、Kafka、React 等技术完全无感知，形成“可独立演进、可快速测试”的内核。
二、知识点详解
2.1 核心领域逻辑（Core Domain Logic）
核心领域逻辑是“业务如何创造核心价值”的抽象，包含：
- 实体（Entity）与值对象（Value Object）：表达业务概念及其不变式。
- 领域服务（Domain Service）：编排跨聚合的纯业务行为。
- 领域事件（Domain Event）：记录业务状态变化的事实。
- 业务规则（Specification/Policy）：以可测试的纯函数或策略对象存在。
这些元素不依赖任何技术框架，仅依赖语言本身和领域通用语言（Ubiquitous Language）。因此，它们可以在内存中快速单元测试，无需启动 Spring 容器或连接真实数据库。
2.2 基础设施功能（Infrastructure Concerns）
基础设施层负责“把领域意图翻译成技术现实”，典型职责包括：
- 持久化适配器：实现 Repository 端口，把聚合根保存到 MySQL、MongoDB 或 Event Store。
- 消息适配器：实现 EventPublisher 端口，把领域事件发布到 Kafka、RabbitMQ。
- 外部服务适配器：调用第三方支付、物流、身份验证服务，并防腐（ACL）。
- UI 适配器：把用户输入转换成应用服务参数，把领域查询结果渲染成 DTO/ViewModel。
这些适配器只负责技术转换，不包含任何业务规则；一旦技术栈升级（如 JPA → jOOQ，Kafka → Pulsar），只需替换对应适配器，领域层代码零改动。
2.3 依赖倒置与端口/适配器模式
为了实现“领域层不依赖基础设施”，必须采用依赖倒置原则（DIP）：
- 领域层定义端口（接口），如
OrderRepository、EventPublisher。 - 基础设施层提供适配器（实现），如
JpaOrderRepository、KafkaEventPublisher。 - 运行时通过依赖注入把适配器注入到应用服务，实现“可插拔”架构。
2.4 分层与包结构落地
在代码层面，常用两种包结构：
-
分层包（Layered Package）
com.example.order ├── application ├── domain │ ├── model │ └── service └── infrastructure├── persistence└── messaging -
按领域分包（Package by Feature / Bounded Context）
com.example.order ├── ordercontext │ ├── application │ ├── domain │ └── infrastructure
无论哪种结构，都需保证领域包不依赖 infrastructure 包，编译时即可验证依赖方向。
三、总结
| 维度 | 核心领域逻辑 | 基础设施功能 |
|---|---|---|
| 关注点 | 业务规则、流程、不变式 | 技术实现、框架、协议 |
| 依赖方向 | 不依赖外部 | 依赖领域端口 |
| 可替换性 | 不可替换（业务核心） | 可插拔（技术细节） |
| 测试方式 | 纯内存单元测试 | 集成测试、契约测试 |
| 示例 | Order、PricingPolicy | JpaOrderRepository、KafkaProducer |
架构师洞见：
把“业务如何赚钱”与“技术如何落地”解耦，是架构可持续演进的关键。掌握该原则后，团队可以：
• 以领域模型为核心进行迭代，避免“技术绑架业务”；
• 在不影响业务逻辑的前提下，平滑迁移到云原生、Serverless 或事件驱动架构；
• 通过“领域层 + 端口”快速构建可测试、可演进的微服务内核。
未来，随着 AI 代码生成、低代码平台的普及，领域模型将越来越成为“唯一需要人工精雕细琢”的资产，而基础设施层则趋向自动化、声明式配置。