DDD（Domain-Driven Design，领域驱动设计）是一种以"业务领域"为核心的软件设计思想，强调通过深入理解业务逻辑来驱动系统设计，而非单纯从技术或数据库角度出发。它解决的核心问题是：当软件系统业务复杂、需求多变时，如何让代码结构与业务逻辑保持一致，避免系统变成难以维护的"大泥球"。

一、DDD的核心思想

1. 以领域为中心：软件的核心价值是解决业务问题，因此设计应围绕业务领域（如电商的"订单领域"、银行的"转账领域"）展开，而非被技术框架（如Spring、数据库）绑架。
2. 分而治之：将复杂领域拆分为多个边界清晰的子领域，降低认知复杂度。
3. 统一语言：开发团队与业务人员使用相同的术语（如"订单状态"“支付流程”），避免沟通偏差，这些术语最终会体现在代码中。

二、DDD的核心概念

1. 领域（Domain）

指软件要解决的业务范围，例如"电商领域"包含商品、订单、支付、物流等业务模块。

2. 子领域（Subdomain）

将复杂领域拆分为更小的子领域，分为三类：

• 核心子领域：业务的核心竞争力（如电商的"订单履约"），需要重点设计。
• 支撑子领域：必要但非核心的业务（如"用户认证"），可复用现有方案。
• 通用子领域：跨领域的通用功能（如"日志"“通知”），可使用第三方组件。

3. 限界上下文（Bounded Context）

• 定义：每个子领域的边界，边界内的领域模型（类、方法、术语）有统一的含义，边界外可能有不同解释。
• 举例：在"订单上下文"中，"商品"可能仅包含ID和价格；而在"商品上下文"中，"商品"包含详情、库存等完整信息。两者虽同名，但含义和结构不同。
• 作用：避免模型混乱，让每个团队专注于自己的上下文。

4. 领域模型的核心元素

这些是构成领域逻辑的"积木"，也是DDD与传统开发的核心区别：

5. 分层架构

DDD通过分层隔离不同职责，避免业务逻辑与技术细节混杂：

• 领域层（Domain Layer）：核心中的核心，包含实体、值对象、聚合、领域服务、领域事件，封装纯业务逻辑。
• 应用层（Application Layer）：协调领域对象完成业务用例（如"创建订单"），不包含业务规则，仅做流程编排。
• 基础设施层（Infrastructure Layer）：提供技术支持，如数据库访问（仓储实现）、消息队列、API调用等。
• 用户接口层（User Interface Layer）：对外暴露接口（如REST API），处理请求参数、返回响应，不包含业务逻辑。

三、DDD的价值

1. 业务与代码一致：代码结构反映业务逻辑，新人能快速通过代码理解业务。
2. 应对复杂业务：通过限界上下文和聚合拆分复杂度，让系统更易维护。
3. 减少沟通成本：统一语言让业务人员和开发人员高效协作。
4. 适应需求变化：领域模型稳定时，技术实现（如数据库、框架）可灵活替换。

简单说，DDD就像"按业务蓝图盖房子"：先搞清楚业务（画蓝图），再确定核心结构（墙、柱、梁对应领域模型），最后才考虑用什么材料（技术框架）。而传统开发更像"先打地基（建数据库），再随便砌墙"，容易导致房子结构与实际需求不符。