领域驱动设计（DDD）

约 1687 字大约 6 分钟

2025-10-10

告别“面条式”代码：领域驱动设计（DDD）入门指南

你是否曾面对一个庞大的项目，却感觉业务逻辑像一团乱麻，散落在各个控制器和服务层中？修改一个简单的业务规则，却需要跨越五六个文件，牵一发而动全身？如果你的答案是肯定的，那么领域驱动设计（Domain-Driven Design, 简称 DDD）可能就是你要寻找的答案。

什么是 DDD？它解决什么问题？

DDD 不是一种框架或技术，而是一套软件开发的方法论和思想体系。它的核心主张是：软件系统的结构应该与它所解决的业务领域高度一致。

想象一下，你在开发一个复杂的电商系统。传统的开发模式可能会让我们不自觉地陷入“数据库驱动设计”的陷阱：我们首先设计数据库表，然后创建对应的实体类，再编写服务层来处理业务逻辑。这种方式导致我们思考的起点是“数据”，而非“业务”。

结果就是：

业务逻辑泄露：本应紧密相关的业务规则，分散在服务层的各个角落。
代码僵化：每次业务变更，都需要在多个层面进行修改，测试和维护成本极高。
沟通障碍：开发人员用技术术语（如“用户表”、“订单表”），业务人员用业务术语（如“客户”、“购物车”），双方鸡同鸭讲。

DDD 正是为了解决这些问题而生。它强调通过通用语言来驱动设计，让软件成为业务领域的精确映射。

DDD 的核心“武器库”

要理解 DDD，你需要掌握以下几个核心概念：

1. 通用语言（Ubiquitous Language）

这是 DDD 的基石。它要求开发团队和业务专家使用一套统一的、无歧义的语言来描述业务。所有文档、代码、对话都应基于此语言。

坏例子：userDao.insert(order); （技术术语）
好例子：customer.placeOrder(cart); （业务术语）通用语言确保了所有人对业务的理解是一致的，从源头上减少了误解。

2. 限界上下文（Bounded Context）

这是 DDD 中最关键的战略模式。一个复杂的领域可以划分为多个限界上下文，每个上下文都是一个独立的业务模块，拥有自己明确的边界和独立的通用语言。

例子：在电商系统中，“商品上下文”和“订单上下文”就是两个不同的限界上下文。
- 商品上下文中关心的“商品”具有丰富的属性：分类、库存、详情描述等。
- 订单上下文中关心的“商品”可能只是一个快照：商品ID、名称、下单时的价格。限界上下文通过定义清晰的边界，避免了模型的“污染”，让系统保持高内聚、低耦合。

3. 领域模型的核心构件（战术模式）

在限界上下文内部，我们使用一系列战术模式来构建领域模型。

实体（Entity）：具有唯一标识和生命周期的对象。例如 Order（订单），通过 OrderId 来区分，即使订单内容完全相同，两个订单也是不同的。
值对象（Value Object）：没有唯一标识，仅通过其属性值来识别的对象。例如 Money（金额），由“数值”和“货币单位”共同定义。两个金额，只要数值和单位相同，它们就是等价的。
聚合根（Aggregate Root）：这是最重要的概念之一。聚合根是一个实体，它定义了一个聚合（一组相关联的实体和值对象的集合）的边界，并作为外部访问聚合的唯一入口。
- 例子：Order（订单）是聚合根，它包含了 OrderItem（订单项）的集合。你不能直接修改或访问 OrderItem，必须通过 Order 这个聚合根。这保证了业务规则（如“订单总金额必须大于0”）在聚合内部得到强制维护。
领域服务（Domain Service）：当某个业务操作不适合放在实体或值对象中时（因为它涉及多个聚合或外部依赖），我们使用领域服务。例如 FundTransferService（资金转账服务），它需要操作“转出账户”和“转入账户”两个聚合。
领域事件（Domain Event）：用于表示在领域中发生的、具有业务意义的事情。例如 OrderConfirmedEvent（订单已确认事件）。当订单被确认后，发布这个事件，后续的“发送通知”、“扣减库存”等操作可以监听并处理它，实现系统间的解耦。

一个简单的代码示例

假设我们有一个“注册用户”的业务规则：用户名不能重复。

没有 DDD 的做法（贫血模型）：

// UserController.java
@RestController
public class UserController {
    @Autowired
    private UserService userService;

    @PostMapping("/users")
    public void createUser(@RequestBody User user) {
        userService.createUser(user);
    }
}

// UserService.java
@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;

    public void createUser(User user) {
        // 业务逻辑散落在服务层
        if (userRepository.existsByName(user.getName())) {
            throw new RuntimeException("用户名已存在");
        }
        userRepository.save(user);
    }
}

使用 DDD 的做法（富血模型）：

// User 实体作为聚合根
public class User {
    private UserId id;
    private String name;

    // 构造函数封装业务规则
    public User(String name, UserRepository userRepository) {
        if (userRepository.existsByName(name)) {
            throw new IllegalArgumentException("用户名已存在");
        }
        this.id = new UserId();
        this.name = name;
    }

    // ... 其他业务方法
}

// 在应用层协调
@Service
public class UserApplicationService {
    @Autowired
    private UserRepository userRepository;

    public void createUser(String userName) {
        // 业务逻辑在领域模型中
        User newUser = new User(userName, userRepository);
        userRepository.save(newUser);
    }
}

可以看到，在 DDD 版本中，“用户名唯一”这个核心业务规则被封装在 User 实体内部，它对自己负责。服务层变得轻薄，只负责协调工作。

什么时候该用 DDD？

DDD 非常强大，但并非银弹。它最适合于：

核心复杂领域：你的系统核心业务逻辑非常复杂，是公司的核心竞争力。
长生命周期项目：项目需要长期迭代和维护。
团队规模较大：需要多人协作，并且与业务专家沟通密切。

对于简单的 CRUD（增删改查）应用，使用 DDD 可能会显得“杀鸡用牛刀”，引入不必要的复杂度。

总结

领域驱动设计（DDD）是一次思维的转变。它引导我们将关注点从“数据”和“技术”回归到“业务”本身。通过通用语言、限界上下文和富有行为的领域模型，我们能构建出更灵活、更健壮、更能响应业务变化的软件系统。