# DDD 与传统开发方式对比

URL: https://caijiao.org/ddd/chapter8/compare
Source: docs/ddd/chapter8/compare.md
Description: 对比领域驱动设计（DDD）与传统开发方式在方法论、模型构建、架构设计等方面的差异。

在软件开发中，领域驱动设计（DDD）被认为是一种应对复杂业务系统的有效方法。与传统的开发方式（如基于数据库设计、功能驱动开发）相比，DDD 在建模方式、系统组织和开发流程等方面有着显著不同。本章节将从多个维度对 DDD 与传统开发方式进行对比分析。

## 1. 建模出发点

| 维度         | 传统开发方式           | DDD                            |
| ------------ | ---------------------- | ------------------------------ |
| 核心出发点   | 数据表结构、UI 界面    | 业务模型与领域逻辑             |
| 数据驱动     | 常见（以表设计为先导） | 拒绝表驱动，强调从业务概念建模 |
| 模型构建依据 | 由数据库或需求文档推导 | 与领域专家沟通抽象核心概念     |

传统开发往往从数据库结构出发，先建表再写逻辑；而 DDD 首先关注业务语言与模型，通过**领域建模**指导数据库设计。

## 2. 层次架构设计

| 维度         | 传统开发方式                             | DDD                                              |
| ------------ | ---------------------------------------- | ------------------------------------------------ |
| 层次划分     | 通常为三层架构（UI、业务逻辑、数据访问） | 明确划分为用户接口层、应用层、领域层、基础设施层 |
| 业务逻辑位置 | 常在 Service 层中堆砌逻辑                | 强调业务逻辑应归属于领域模型                     |
| 解耦程度     | 松散，往往 UI、数据库绑定严重            | 高内聚、明确职责边界，鼓励解耦                   |

DDD 推崇**高内聚、低耦合**的架构模型，促使代码围绕业务意图组织。

## 3. 领域模型使用

| 维度     | 传统开发方式               | DDD                              |
| -------- | -------------------------- | -------------------------------- |
| 实体设计 | 常以数据库结构为基础创建类 | 以业务语义为中心设计实体与值对象 |
| 模型职责 | 倾向贫血模型（只有属性）   | 倾向充血模型（包含业务行为）     |
| 关注点   | 读写数据                   | 表达业务规则与行为               |

DDD 的领域模型是一种**表达能力强的业务抽象工具**，不仅仅用于存储数据。

## 4. 与业务协作方式

| 维度         | 传统开发方式                     | DDD                                       |
| ------------ | -------------------------------- | ----------------------------------------- |
| 与业务沟通   | 需求文档驱动，需求-开发存在割裂  | 倡导与领域专家持续沟通，构建通用语言      |
| 语言一致性   | 存在术语混乱、歧义               | 全系统统一通用语言（Ubiquitous Language） |
| 变更适应能力 | 应对变更成本高，改表、改流程繁琐 | 领域模型可持续演进，适应复杂业务变更      |

DDD 更适合**需要长期迭代、业务规则复杂**的系统开发。

## 5. 数据与逻辑的关系

| 维度       | 传统开发方式                       | DDD                                |
| ---------- | ---------------------------------- | ---------------------------------- |
| 数据优先级 | 数据为中心，逻辑围绕数据组织       | 行为为中心，数据作为行为的载体     |
| 持久化策略 | 强耦合于数据库（如 Active Record） | 弱化持久化，实现基础设施与领域解耦 |

DDD 中，数据库是技术细节，不是建模核心，强调用仓储（Repository）隔离持久化逻辑。

## 6. 面向变化的能力

| 维度     | 传统开发方式               | DDD                          |
| -------- | -------------------------- | ---------------------------- |
| 变更响应 | 模块间耦合高，响应变更困难 | 上下文边界清晰，模型适应性强 |
| 模型演进 | 数据库变动引发大量连锁反应 | 支持通过领域模型重构逐步演进 |

DDD 注重**灵活性和模型演进能力**，能更好地支持业务创新与扩展。

## 总结

| 对比维度 | 传统开发方式       | DDD                |
| -------- | ------------------ | ------------------ |
| 建模思维 | 数据/功能导向      | 业务/领域导向      |
| 架构方式 | 三层结构           | 四层分明、强调职责 |
| 模型设计 | 贫血模型、结构为主 | 充血模型、行为为主 |
| 业务协作 | 文档沟通、割裂     | 通用语言、深度协作 |
| 适用场景 | 简单系统、短期项目 | 复杂系统、核心业务 |

DDD 是一场“从技术到业务”的思想转变。它要求开发者不仅能写代码，更要成为**业务建模专家**。理解与掌握 DDD 的关键在于**与业务对话、从业务中抽象模型**，这正是它区别于传统开发方式的最大价值所在。