1.DDD是什么

领域驱动设计（英语：Domain-driven design，缩写 DDD）
是一种由域模型来驱动着系统设计的思想，而不是通过DB表字段等数据字典来驱动系统设计来满足复杂需求的软件开发方法。领域模型是对业务模型的抽象，DDD是把业务模型翻译成系统架构设计的一种方式。

---

2.DDD 解决了什么问题

统一思想：统一项目各方业务、产品、开发对问题的认知，而不是开发和产品统一，业务又和产品统一从而产生分歧。

明确分工：域模型需要明确定义来解决方方面面的问题，而针对这些问题则形成了团队分钟的理解。

反映变化：需求是不断变化的，因此我们的模型也是在不断的变化的。领域模型则可以真实的反映这些变化。

边界分离：领域模型与数据模型分离，用领域模型来界定哪些需求在什么地方实现，保持结构清晰。

---

3.概念

3.1 什么是领域

任何一个系统都会属于某个特定的领域，比如论坛是一个领域，只要你想做一个论坛，那这个论坛的核心业务是确定的，比如都有用户发帖、回帖等核心基本功能。比如电商平台、普通电商系统，这种都属于网上电商领域，只要是这个领域的系统，那都有商品浏览、购物车、下单、减库存、付款交易等核心环节。所以，同一个领域的系统都具有相同的核心业务，因为他们要解决的问题的本质是类似的。

因此，我们可以推断出，一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题域就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、问题的范围边界就基本确定了。通常我们说，要成为一个领域的专家，必须要在这个领域深入研究很多年才行。因为只有你研究了很多年，你才会遇到非常多的该领域的问题，同时你解决这个领域中的问题的经验也非常丰富。

3.2 什么是驱动

1）领域驱动领域模型设计；
2）领域模型驱动代码实现。
我们只要保证领域模型的设计是正确的，就能确定领域模型可以解决领域中的核心问题；同理，我们只要保证代码实现是严格按照领域模型的意图来落地的，那就能保证最后出来的代码能够解决领域的核心问题的。这个思路，和传统的分析、设计、编码这几个阶段被割裂（并且每个阶段的产物也不同）的软件开发方法学形成鲜明的对比。

3.3 概念总结

1. 领域就是问题域，有边界，领域中有很多问题；
2. 任何一个系统要解决的那个大问题都对应一个领域；
3. 通过建立领域模型来解决领域中的核心问题，模型驱动的思想；
4. 领域建模的目标针对我们在领域中所关心的问题，即只针对核心关注点，而不是整个领域中的所有问题；
5. 领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值；
6. 通过领域模型驱动代码的实现，确保代码让领域模型落地，代码最终能解决问题；
7. 领域模型是系统的核心，是领域内的业务的直接沉淀，具有非常大的业务价值；
8. 技术架构设计或数据存储等是在领域模型的外围，帮助领域模型进行落地；

---

4.DDD术语

实体
一个由它的标识定义的对象叫做实体”。通常实体具备唯一id，能够被持久化，具有业务逻辑，对应现实世界业务对象

值对象
依附于实体存在，通过对象属性来识别的对象，它将一些相关的实体属性打包在一起处理，形成一个新的对象。

聚合
实体和值对象表现的是个体的能力，而我们的业务逻辑往往很复杂，依赖个体是无法完成的，这时候就需要多个实体和值对象一起协同工作，而这个协同的组织就是聚合。聚合是数据修改和持久化的基本单元，同一个聚合内要保证事务的一致性，所以在设计的时候要保证聚合的设计拆分到最小化以保证效率和性能。

聚合根
也叫做根实体，一个特殊的实体，它是聚合的管理者，代表聚合的入口，抓住聚合根可以抓住整个聚合。

通用语言
专门描述你的有界上下文里面的各种事情，动作，操作，行为，名词，事务。字段，数据，状态，命令，事件，统一命名规范 （开发、产品、业务人员的共识）

下一篇将会介绍如何实践DDD并将概率使用起来