主题
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 的关键在于与业务对话、从业务中抽象模型，这正是它区别于传统开发方式的最大价值所在。