当前位置：首页 > news >正文

领域驱动设计（DDD）是什么？

news 来源：原创 2025/5/9 20:00:17

领域驱动设计（DDD）是什么？

在软件开发的世界里，我们总在寻找那把打开业务之门的钥匙。有人迷恋MVC的简洁，有人追逐微服务的潮流，而DDD（领域驱动设计）则像一位沉默的智者，提醒着我们：软件不是代码的堆砌，而是对现实世界的映射。

在软件开发中，你是否遇到过这些问题？

业务逻辑散落各处，修改一个需求需要改动几十个文件。
系统迭代后变成“大泥球”，新成员上手需要啃几个月代码。
技术语言与业务语言割裂，开发与产品经理频繁“鸡同鸭讲”。

这些痛点背后的本质是：软件复杂性失控。而领域驱动设计（Domain-Driven Design，DDD）正是为解决这些问题而生。

一、DDD是什么？

DDD：不是框架，而是一种思维方式

1. 核心哲学的三重维度

认知维度：建立开发团队与业务专家的统一语言
（如将"用户授信"转化为CreditEvaluation领域服务）
架构维度：通过限界上下文切割业务复杂度
（支付上下文与风控上下文的关系如同两个国家的贸易协定）
工程维度：充血模型让代码成为活的业务文档
（对比传统贫血模型，DDD的Order类包含calculateTotal()等业务方法）

DDD（Domain-Driven Design）是一种以业务领域为核心的软件设计方法，由Eric Evans在2003年提出。它并非具体的技术框架或工具，而是一套应对复杂业务系统的设计哲学和实践方法论。

DDD的核心目标：

消除技术实现与业务需求的鸿沟
通过领域模型管理复杂性
构建可持续演进的软件系统

类比理解：
传统开发如同“拼乐高”——按图纸组装固定模块；
DDD开发则是“造乐高”——先理解用户想构建什么，再设计专属的积木块。

二、DDD的核心理念

1. 统一语言（Ubiquitous Language）

问题：开发用“User”，产品说“客户”，DBA称“account”
解法：建立团队共识的术语表

// 代码体现统一语言  
public class Customer {  // 统一使用"客户"而非"用户"
    private CustomerId id;  
    private AccountCollection accounts; // 账户集合
}

2. 限界上下文（Bounded Context）

定义：业务子领域的独立边界
案例：电商系统中的“订单上下文” vs “支付上下文”

上下文	核心概念	交互方式
订单上下文	购物车、优惠券、库存预留	发布“订单已创建”事件
支付上下文	支付单、退款规则、渠道对接	监听事件触发支付流程

3. 领域模型（Domain Model）

传统贫血模型 vs DDD充血模型：

// 贫血模型：数据与行为分离
public class Order {
    private Long id;
    private BigDecimal amount;
}

public class OrderService {
    public void applyDiscount(Order order, BigDecimal discount) {
        order.setAmount(order.getAmount().multiply(discount));
    }
}

// 充血模型：行为内聚在领域对象
public class Order {
    private Long id;
    private BigDecimal amount;
    
    public void applyDiscount(BigDecimal discount) {
        this.amount = this.amount.multiply(discount);
    }
}

三、DDD的核心模式

1. 战略设计：划分业务版图

事件风暴（Event Storming）：通过领域事件识别业务边界
上下文映射（Context Mapping）：定义跨上下文协作模式

2. 战术设计：构建领域模型

（1）领域对象类型

类型	定义	案例
实体（Entity）	唯一标识 + 可变状态	用户(User)、订单(Order)
值对象（Value Object）	不可变属性集合	地址(Address)、金额(Money)
聚合（Aggregate）	一致性边界的领域对象集群	订单聚合（含Order、OrderItem）

（2）分层架构

├── interfaces    // 适配层：对接外部输入（API/消息）
├── application   // 应用层：编排领域对象完成用例
├── domain        // 领域层：充血模型核心
└── infrastructure// 基础设施：数据库/缓存实现

四、DDD的落地实践

1. 仓储模式（Repository）

传统DAO vs DDD仓储：

// 传统DAO：直接操作数据库
public interface OrderDao {
    void insert(Order order);
}

// DDD仓储：领域模型与持久化的桥梁
public interface OrderRepository {
    Order findById(OrderId id);
    void save(Order order);
}

// 基础设施层实现
@Repository
public class JpaOrderRepository implements OrderRepository {
    @Override
    public Order findById(OrderId id) {
        // 调用JPA实现查询
    }
}

2. 领域事件（Domain Event）

public class OrderPaidEvent {
    private OrderId orderId;
    private LocalDateTime paidTime;
}

// 应用服务发布事件
public class OrderApplicationService {
    @Transactional
    public void payOrder(OrderId id) {
        Order order = repository.findById(id);
        order.pay();
        eventPublisher.publish(new OrderPaidEvent(order.getId()));
    }
}