背景

传统开发的方式会出现的问题：

1. 大泥球 ( big ball of mud )，代码边界模糊
2. 产品文档库缺失，功能追踪复杂

项目变复杂之后，需要划分边界，搞清关系，而 DDD 就是一种边界划分的指导思想

• DDD 是适用于 复杂软件设计的，简单的不适用
• 建模需要领域专家 和 研发同学一起参与 (领域专家在我们这是 PM)
• 不同人背景不同，协作需要使用一套共同的语言

领域

核心域： 决定产品和公司核心竞争力的领域。对应到我们就是工作台和画布。
通用域： 和特定产品和企业没太多关系，大家都一样的。例如 用户域。
支撑域： 支撑维度的领域，比如 管理后台 等。

限界上下文

一个场景的相关实体

实体

领域内的主要成员，实体是领域驱动的核心。对应我们来说，例如 user、team、project、document、comment、file 等等。
实体 是有 动作 的，比如 user 要 登录。

值对象

一些实体的特征或状态的描述，例如对用户而言，有 住址、性别 等。

聚合

把实体进行组合的过程，就是 聚合。
是基于一些场景来聚合。比如，根据 用户、微信登录、密码操作 等场景进行聚合，就是一个聚合，可能就是 账户中心 的原型。
聚合是一个非常重要的环节，聚合地好坏基本决定了架构的好坏。
事件风暴 是一种建模的方式。

战略设计和战术设计

战略设计： 以业务视角，拆分领域，通过事件风暴(从发散到收敛) 的方法，梳理出一套领域模型。
战术设计： 代码结构和部署结构，与战略设计的模型一一对应。

战略设计得出的东西，对于 产品经理、研发人员 等等都能很好理解。战术设计出的东西，研发人员理解的内容。 两者保持一致，能够让大家的理解统一，大家都知道某一部分是做什么的。

四层架构

用户接口层 (提供接口)
应用层 (做领域的聚合，提供业务逻辑)
领域层 (领域逻辑)
基础层 (存储、数据库、缓存、api网关、基础服务、工具 等)

接口层（Interfaces）
1. 如Web服务器、RESTful接口、CMD入口
2. 处理传入数据的解释、校验、编解码、序列化操作
应用层（Application）
1. 很薄的一层，通常不应该包含具体业务逻辑。
2. 协调多个领域对象(实体、聚合根、领域服务)实现服务编排和组合
3. 分布式事务、消息、日志记录通常也是在该层
领域层（Domain）
1. 该层是软件的核心，包含业务逻辑具体实现，包含实体、值对象、聚合、领域服务、存储接口
2. 不依赖其它层
基础层（Infrastructure）
1. 基础层以不同方式支持到其他三层，促进各层间通信
2. 包含网关、缓存、数据库存储、消息中间件、监控、应用程序服务等通用的技术和基础服务
3. 配置文件，数据库Schema模式定义以及存储接口实现

领域层不依赖与任何层，使用接口，可以独立进行测试。

原则

1. 通用语言业务人员和开发人员需要使用无歧义的统一语言来对话。
2. 核心域就是最关键的业务逻辑，聚焦核心域决定了软件的定位和投资重心。
3. 协作共创是指领域专家和业务专家共同建模。
4. 持续建模是指模型需要随业务变化而被及时更新。

阅读

• 《领域驱动设计》Eric Evans ，提出 DDD 概念
• 《实现领域驱动设计》Vaughn Vernon，指导 DDD 落地
• 《领域驱动设计模式、原理与实践》Scott Millett / Nick Tune
• 《DDD 实战课》极客时间

---

Cleverness is not wisdom.
— Euripides