为什么使用实体

当我们需要考虑一个对象的个性特征，或者需要区分不同的对象时，我们引人实体这个领域概念。一个实体是一个唯一的东西，并且可以在相当长的一段时间内持续地变化。我们可以对实体做多次修改，故一个实体对象可能和它先前的状态大不相同。但是，由于它们拥有相同的身份标识(identity)，它们依然是同一个实体。

随着对象的改变，我们可能会跟踪这样的改变过程，比如什么时候发生了改变，发生了什么改变，是谁做出的改变等。也或者，当前对象中已经包含了足够的先前状态的改变信息，此时我们便没有必要显式地对对象状态进行跟踪。即便我们并不打算跟踪对象的每一个变化细节,我们也应该慎重对待在对象整个生命周期中所发生的合法改变。唯一的身份标识和可变性(mutability)特征将实体对象和值对象(Value Objects, 6)区分开来。

有时，实体并不见得是一种适当的建模工具，而我们对实体的使用也有可能是不恰当的。很多时候，一个领域概念应该建模成值对象，而不是实体对象。这也意味着DDD并不总能满足我们的业务需求，一个基于CRUD (译注：Create、Retrieve、Update、Delete,即增删改查）的软件系统可能更加合适，同时又可以为你节约了时间和金钱。但问题是，购买一套基于CRUD的软件系统通常并不能为你节约这两种宝贵的资源。

我们将太多的投人放在开发数据库表编辑器上。但是如果工具选择不当，一个基于CRUD的系统可能是非常昂贵的。在有理由使用CRUD时，对语言和框架的选择就很重要了，此时可以选择Groovy和Grails、Ruby oil Rails等。

另一方面，如果我们将CRUD应用在了错误的系统上那些更复杂的，需要采用DDD的系统一一就有我们后悔的了。随着软件复杂性的增加，我们就越能体会到由错误的工具选择所带来的限制。由于只从数据出发，CRUD系统是不能创建出好的业务模型的。

在可以使用DDD的情况下，我们会将数据模型转变为实体模型。

我们通过标识对对象进行区分，而不是属性，此时我们应该将标识作为主要的模型定义。同时我们需要保持简单的类定义，并且关注对象在其生命周期中的连续性和唯一标识性„我们不应该通过对象的状态形式和历史来区分不同的实体对象……对于什么是相同的东西，模型应该给出定义。[Evans, p.92]

在本章中，我们将学到如何正确地使用和设计实体。