2004年Eric Evans 发表《领域驱动设计——软件核心复杂性应对之道》（Domain-Driven Design –Tackling Complexity in the Heart of Software），简称Evans DDD，领域驱动设计思想进入软件开发者的视野。领域驱动设计分为两个阶段：

在传统模型中，对象是数据的载体，只有简单的getter/setter方法，没有行为。以数据为中心，以数据库ER设计作驱动。分层架构在这种开发模式下，可以理解为是对数据移动、处理和实现的过程。业务逻辑都是写在Service中的，对象充其量只是个数据载体，没有任何行为，是一种贫血模型。

传统架构的特点：

与面向对象中的概念类似，在这里再次提出是因为它是领域模型的基本元素。在领域模型中，实体应该具有唯一的标识符。

从设计的一开始就应该考虑实体，决定是否建立一个实体也是十分重要的。另外，不应该给实体定义太多的属性或行为，而应该寻找关联，发现其他一些实体或值对象，将属性或行为转移到其他关联的实体或值对象上。

比如Customer实体，他有一些地址信息，由于地址信息是一个完整的有业务含义的概念，所以，我们可以定义一个Address对象，然后把Customer的地址相关的信息转移到Address对象上。如果没有Address对象，而把这些地址信息直接放在Customer对象上，并且如果对于一些其他的类似Address的信息也都直接放在Customer上，会导致Customer对象很混乱，结构不清晰，最终导致它难以维护和理解；

与编程中数值类型的变量是不同的，它仅仅是没有唯一标识符的实体，如果两个对象的所有的属性的值都相同我们会认为它们是同一个对象的话，那么我们就可以把这种对象设计为值对象。值对象在领域模型中是可以被共享的，他们应该是“不可变的”（只读的），当有其他地方需要用到值对象时，可以将它的副本作为参数传递。当共享值对象时，一般有复制和共享两种做法。

如果有两个Customer的地址信息是一样的，我们就会认为这两个Customer的地址是同一个。

领域中的一些概念不太适合建模为对象，即归类到实体对象或值对象，因为它们本质上就是一些操作，一些动作，而不是事物。这些操作或动作往往会涉及到多个领域对象，并且需要协调这些领域对象共同完成这个操作或动作。如果强行将这些操作职责分配给任何一个对象，则被分配的对象就是承担一些不该承担的职责，从而会导致对象的职责不明确很混乱。但是基于类的面向对象语言规定任何属性或行为都必须放在对象里面。所以我们需要寻找一种新的模式来表示这种跨多个对象的操作，DDD认为服务是一个很自然的范式用来对应这种跨多个对象的操作，所以就有了领域服务这个模式。

服务是无状态的，对象是有状态的。所谓状态，就是对象的基本属性：高矮胖瘦，年轻漂亮。服务本身也是对象，但它却没有属性（只有行为），因此说是无状态的。

服务存在的目的就是为领域提供简单的方法。为了提供大量便捷的方法，自然要关联许多领域模型，所以说，行为(Action)天生就应该存在于服务中。

服务具有以下特点：

领域服务存在的意义就是协调领域对象共完成某个操作，所有的状态还是都保存在相应的领域对象中。模型（实体）与服务（场景）是对领域的一种划分，模型关注领域的个体行为，场景关注领域的群体行为，模型关注领域的静态结构，场景关注领域的动态功能。

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

举个简单的例子，一个电脑包含硬盘、CPU、内存条等，这一个组合就是一个聚合，而电脑就是这个组合的聚合根。

聚合有以下一些特点：

如何识别聚合？

所谓关系是内聚的，是指这些对象之间必须保持一个固定规则，固定规则是指在数据变化时必须保持不变的一致性规则。当我们在修改一个聚合时，我们必须在事务级别确保整个聚合内的所有对象满足这个固定规则。

如何识别聚合根？

有时创建一个领域对象是一件比较复杂的事情，不仅仅是简单的new操作。正如对象封装了内部实现一样（我们无需知道对象的内部实现就可以使用对象的行为），工厂则是用来封装创建一个复杂对象尤其是聚合时所需的知识，工厂的作用是将创建对象的细节隐藏起来。客户传递给工厂一些简单的参数，然后工厂可以在内部创建出一个复杂的领域对象然后返回给客户。

工厂在创建一个复杂的领域对象时，通常会知道该满足什么业务规则（它知道先怎样实例化一个对象，然后在对这个对象做哪些初始化操作，这些知识就是创建对象的细节），如果传递进来的参数符合创建对象的业务规则，则可以顺利创建相应的对象；但是如果由于参数无效等原因不能创建出期望的对象时，应该抛出一个异常，以确保不会创建出一个错误的对象。当然我们也并不总是需要通过工厂来创建对象，事实上大部分情况下领域对象的创建都不会太复杂，所以我们只需要简单的使用构造函数创建对象就可以了。隐藏创建对象的好处是显而易见的，这样可以不会让领域层的业务逻辑泄露到应用层，同时也减轻了应用层的负担，它只需要简单的调用领域工厂创建出期望的对象即可。

资源库的是封装所有获取对象引用所需的逻辑。领域对象不需处理基础设施，以得到领域中对其他对象的所需的引用。只需从资源库中获取它们，于是模型重获它应有的清晰和焦点。

资源库会保存对某些对象的引用。当一个对象被创建出来时，它可以被保存到资源库中，然后以后使用时可从资源库中检索到。如果客户程序从资源库中请求一个对象，而资源库中并没有它，就会从存储介质中获取它。换种说法是，资源库作为一个全局的可访问对象的存储点而存在。

Repository的接口应当采用领域通用语言。作为客户端，不应当知道数据库实现的细节。

Repository和DAO的作用类似，二者的主要区别：

DAO是比Repository更低的一层，包含了如何从数据库中提取数据的代码。

Repository以“领域”为中心，所描述的是“领域语言”。Repository把ORM框架与领域模型隔离，对外隐藏封装了数据访问机制。

工厂和资源库之间存在一定的关系。它们都是模型驱动设计中的模式，它们都能帮助我们关联领域对象的生命周期。然而工厂关注的是对象的创建，而资源库关心的是已经存在的对象。资源库可能会 在本地缓存对象，但更常见的情况是需要从一个持久化存储中检索 它们。对象可以用构造函数创建，也可以被传递给一个工厂来构 建。从这个原因上讲，资源库也可以被看作一个工厂，因为它创建对象。不过它不是从无到有创建新的对象，而是对已有对象的重建。我们将不把资源库视为一个工厂。工厂创建新的对象，而资源库应该是用来发现已经创建过的对象。当一个新对象被添加到资源库时，它应该是先由工厂创建过的，然后它应该被传递给资源库以便将来保存它，见下面的例子:

采用DDD的设计思想，业务逻辑不再集中在几个大型的类上，而是由大量相对小的领域对象(类)组成，这些类具备自己的状态和行为，每个类是相对完整的独立体，并与现实领域的业务对象映射。领域模型就是由这样许多的细粒度的类组成。

领域驱动设计告诉我们，在通过软件实现一个业务系统时，建立一个领域模型是非常重要和必要的，因为领域模型具有以下特点：

讯享网

大家都去超市买过东西，对超市收银业务都比较熟悉。什么？你不熟？好吧，那我们找个收银员给大家讲解下（领域专家）。

收银员小慧：哦，是这样呢。顾客排队银帐我就收银呢，我要使用收银机呢。收银机就能计算出要收的钱呢，我就扫一下呢，就OK了呢。然后就收银了呢。

听了小慧的讲解，我们心中有了业务的概念了。我们这里采用《业务关键字分析法》来找出此业务流程里面的一些关系字：

好了，列出这些“业务关键字”了，我们就可以建我们的对象模型了。

上面我们分析出了一些“业务关键字”接下来我们分析这些业务关键字并深入他们的业务。

商品对象(Goods)

属性：商品名称(GoodsName)、商品价格(GoodsPrice)。

行为：在这里商品对象是没有行为的，我们也可以叫它“值对象”。

顾客对象(Customer)

属性：顾客姓名(CustomerName)、顾客选购的商品(Goodss)

行为：选购想买的商品(LikeBuy)、听收银员说要收多少RMB(ListenAmount)

收银员对象(Cashier)

属性：收银员姓名(CashierName)

行为：收银(CashierRegister)

收银机对象(CashierRegister)

属性：收银机编号(CashRegisterNo)

字段：总金额(_totalAmount)

行为：收银(CashRegisters)、显示收银总额(ShowAmount)

有木有很直观，这也就是面向对象分析的好处，因为对象就是对现实的抽象，我们现实中的事务可以很方便的用对象抽象出来。我们很容易发现，这和用表来描述这些业务模型显然要不方便的多。表还只能描述属性，造成了属性与行为的分离。

商品对象

顾客对象

收银员对象

收银机对象

模拟业务流程

显示结果

：

：

：