什么是领域驱动设计（DDD）？

前面介绍了 Spring 应用的缺陷。本文将会介绍 DDD 的相关概念。

DDD总体结构分为四层: Infrastructure(基础实施层)，Domain(领域层)，Application(应用层)，Interfaces(表示层，也叫用户界面层或是接口层)，各个层面的作用下面介绍。

• 用户界面（表现层）：负责给用户展示信息，并解释用户命令。
• 应用层：该层协调应用程序的活动。不包括任何业务逻辑，不保存业务对象的状态，但能保存应用程序任务过程的状态。
• 领域层：这一层包括业务领域的信息。业务对象的状态在这里保存。业务对象的持久化和它们的状态可能会委托给基础设施层。
• 基础设施层：对其它层来说，这一层是一个支持性的库。它提供层之间的信息传递，实现业务对象的持久化，包含对用户界面层的支持性库等。

基本概念

实体（Entity）

当一个对象由其标识(而不是属性)区分时，这种对象称为实体(Entity)。比如当两个对象的标识不同时，即使两个对象的其他属性全都相同，我们也认为他们是两个完全不同的实体。

值对象（Value Object）

当一个对象用于对事物进行描述而没有唯一标识时，那么它被称作值对象。因为在领域中并不是任何时候一个事物都需要有一个唯一的标识，也就是说我们并不关心具体是哪个事物，只关心这个事物是什么。比如下单流程中，对于配送地址来说，只要是地址信息相同，我们就认为是同一个配送地址。由于不具有唯一标示，我们也不能说"这一个"值对象或者"那一个"值对象。

领域服务（Domain Service）

一些重要的领域行为或操作，它们不太适合建模为实体对象或者值对象，它们本质上只是一些操作，并不是具体的事物，另一方面这些操作往往又会涉及到多个领域对象的操作，它们只负责来协调这些领域对象完成操作而已，那么我们可以归类它们为领域服务。它实现了全部业务逻辑并且通过各种校验手段保证业务的正确性。同时呢，它也能避免在应用层出现领域逻辑。理解起来，领域服务有点facade的味道。

聚合及聚合根（Aggregate，Aggregate Root）

聚合是通过定义领域对象之间清晰的所属关系以及边界来实现领域模型的内聚，以此来避免形成错综复杂的、难以维护的对象关系网。聚合定义了一组具有内聚关系的相关领域对象的集合，我们可以把聚合看作是一个修改数据的单元。

聚合根属于实体对象，它是领域对象中一个高度内聚的核心对象。(聚合根具有全局的唯一标识，而实体只有在聚合内部有唯一的本地标识，值对象没有唯一标识，不存在这个值对象或那个值对象的说法)

若一个聚合仅有一个实体，那这个实体就是聚合根；但要有多个实体，我们就要思考聚合内哪个对象有独立存在的意义且可以和外部领域直接进行交互。

工厂（Factory）

DDD中的工厂也是一种封装思想的体现。引入工厂的原因是：有时创建一个领域对象是一件相对比较复杂的事情，而不是简单的new操作。工厂的作用是隐藏创建对象的细节。事实上大部分情况下，领域对象的创建都不会相对太复杂，故我们仅需使用简单的构造函数创建对象就可以。隐藏创建对象细节的好处是显而易见的，这样就可以不会让领域层的业务逻辑泄露到应用层，同时也减轻应用层负担，它只要简单调用领域工厂来创建出期望的对象就可以了。

仓储（Repository）

资源仓储封装了基础设施来提供查询和持久化聚合操作。这样能够让我们始终关注在模型层面，把对象的存储和访问都委托给资源库来完成。它不是数据库的封装，而是领域层与基础设施之间的桥梁。DDD 关心的是领域内的模型，而不是数据库的操作。

小结

本文介绍了 DDD 的相关概念。DDD 概念理解起来有点抽象，这个有点像设计模式，感觉很有用，但是自己开发的时候又不知道怎么应用到代码里面，或者生搬硬套后自己看起来都很别扭。下面的文章，我们将会介绍 DDD 相关的设计思想。

订阅最新文章，欢迎关注我的公众号：aoho 求索

参考

1. Spring Web 应用的最大瑕疵
2. 领域驱动设计(DDD)