4.1.5  领域驱动设计

在处理复杂业务逻辑时，Domain Model模式非常有用。而DDD(Domain-Driven Design，领域驱动设计)就是一种流行的利用Domain Model模式的设计方法学。

简而言之，DDD就是一组帮助人们构建能够反映业务理解并满足业务需求的应用程序的模式和原则。除此之外，它还是一种思考开发方法学的新方法。DDD探讨对真实领域建模，首先要全面理解该领域，并将所有的术语、规则和逻辑放入到代码的抽象表示(通常是以领域模型的形式)中。

下面将介绍DDD的主要方面，这是本书剩余部分中的大多数练习均要使用的方法学。

1. 通用语言

通用语言(ubiquitous language)的概念是，它应该充当一个公共词汇表，开发者、领域专家及任何其他参与项目的人都使用它来描述该领域。领域专家具有特定领域知识和技能，并且在开发领域模型的过程中与您密切协作，以确保在尝试使用代码表示业务模型之前完全理解该模型。在贷款应用程序中，担保人就可能是领域专家。通过听取此人的讲解，可以构建一个囊括了在申请贷款过程中使用的所有术语的词汇表。所编写的类、方法和属性名称都应该基于同样的通用语言。这可以让您使用领域专家能够理解的语言来谈论代码。此外，接触该代码的新开发者也应该能够了解该领域。它还让他们能够以相对容易的方式与业务专家谈论复杂业务逻辑的哪怕是最细微的细节。当参与应用程序开发的各方都使用相同的语言时，人们就可以容易地表达问题和解决方法，从而让应用程序更快、更容易地构建。

DDD并不是一个框架，但它确实有一组构建块或概念可供整合到解决方案中。在下面将逐个介绍这些概念。

2. 实体

实体就是4.1.3小节中曾经讨论过的事物，如电子商务网站中的订单、客户、商品，博客应用程序中的博客和帖子对象。它们以一种抽象的方式包含了真实实体中的数据和行为。任何与实体相关的逻辑都应该包含在它内部。实体属于需要标识符的事物，在其整个生命周期中，该标识符都将保持不变。考虑贷款应用程序中的借款人。借款人有姓名，但姓名可能变化也可能重复，因此需要添加一个单独的标识，借款人在该借款应用程序的整个生命周期中该标识将保持不变，无论其姓名、职业或地址改变与否。通常，系统使用某种唯一标识符或自动编号值来为所有无法采用自然方式标识的实体提供标识符。有时候，实体确实具有自然键，如社会保险号或员工号码。并不是领域模型中的所有对象都是唯一的而且需要标识。对于某些对象，数据是最重要的，而不是标识。这些对象就被称为值对象。

3. 值对象

值对象没有标识，它们之所以重要只是因为它们的特性。值对象通常并不会单独存在，它们通常是(但并非总是)实体的属性。回顾4.1.3小节中编写的简单银行账号应用程序，应该记得Transaction对象没有标识，这是因为它只存在于与之相关的银行账号实体中，它是一个值对象，在其上下文中它本身并不单独存在。