领域驱动设计概述

领域驱动设计（Domain-Driven Design，DDD）是一种软件开发方法论，强调通过领域模型（Domain Model）解决复杂业务问题。其核心思想是将业务逻辑与技术实现分离，通过统一语言（Ubiquitous Language）促进开发团队与领域专家的协作。

核心概念

领域模型
领域模型是对业务问题的抽象表示，通常以对象或数据结构体现。例如，电商系统中的“订单”、“库存”等实体。

限界上下文（Bounded Context）
限界上下文是领域模型的边界，用于明确模型的适用范围。不同上下文可能对同一术语有不同定义，例如“客户”在销售与物流上下文中含义不同。

统一语言
开发团队与业务专家使用一致的术语描述业务逻辑，避免歧义。统一语言直接体现在代码、文档和对话中。

分层架构
DDD通常采用分层架构：

• 用户界面层：处理交互与展示。
• 应用层：协调领域逻辑与基础设施。
• 领域层：包含核心业务逻辑与模型。
• 基础设施层：提供技术实现（如数据库、消息队列）。

战术设计模式

实体（Entity）
具有唯一标识的对象，例如“用户”通过ID区分。

值对象（Value Object）
通过属性定义的对象，无唯一标识，例如“地址”。

聚合根（Aggregate Root）
一组相关对象的入口点，保证数据一致性。例如“订单”聚合根包含订单项与支付信息。

领域服务（Domain Service）
处理跨聚合的逻辑，例如“转账服务”涉及多个账户操作。

仓储（Repository）
封装数据访问逻辑，提供聚合根的持久化接口。

战略设计模式

上下文映射（Context Mapping）
描述不同限界上下文间的关系，常见模式包括：

• 合作关系（Partnership）：两个上下文相互依赖。
• 共享内核（Shared Kernel）：共享部分模型与代码。
• 防腐层（Anticorruption Layer）：隔离外部系统的影响。

实施步骤

1. 领域分析
与业务专家协作，识别核心子域（Core Domain）、支撑子域（Supporting Subdomain）和通用子域（Generic Subdomain）。

2. 模型设计
通过事件风暴（Event Storming）或用例分析提炼领域模型，明确实体、值对象和聚合边界。

3. 代码实现
将模型转化为代码，使用领域层隔离业务逻辑，避免基础设施代码污染核心逻辑。

4. 持续演进
通过迭代优化模型，适应业务变化。例如拆分过大的聚合或合并重复的逻辑。

示例代码

// 聚合根示例：订单  
public class Order {  
    private String orderId;  
    private List<OrderItem> items;  

    public void addItem(Product product, int quantity) {  
        // 业务逻辑验证  
        items.add(new OrderItem(product, quantity));  
    }  
}  

// 值对象示例：地址  
public record Address(String street, String city) {}  

适用场景

• 业务逻辑复杂的系统（如金融、电商）。
• 需要长期演进的项目，模型需随业务调整。
• 跨团队协作时，需明确上下文边界。

常见误区

• 过度设计：在简单场景中强行应用DDD，增加复杂性。
• 技术驱动：忽略业务专家参与，导致模型偏离实际需求。
• 忽略上下文映射：未明确上下文关系，引发集成问题。