模型由模型元素的几种模式在代码中表示：

值对象实体关联服务套餐模块值对象

值对象是描述其他事物状态的属性。它们没有概念上的同一性，它们描述了另一个对象的特征。它们是其他对象的属性。

值对象与实体的不同之处在于它们需要被跟踪的方式。如果只有值是相关的，我们就存在一个值对象。如果我们指的是什么值也相关，那么我们就存在一个实体。

实体

实体是表示域模型中相关事物的对象。它们独立存在，不能被具有相同数据的另一个对象交换，它们在领域逻辑中至关重要。

本书中提供的示例是体育场内的座位。如果我们的域表示每张票都有分配给它的特定座位，那么我们需要在整个应用程序中跟踪这个座位并且它有一个特定的标识：它是和实体。但是，如果机票和座位之间没有任何联系，那么座位只是一个泛型的东西，它可以是任何一个座位，可以互换，我们不需要跟踪它，它没有特定的身份：它不是一个实体。但是，它可能是一个值对象，具有颜色、大小、重量等。

从技术上讲，实体实现应该非常简洁，只包含定义它的属性和特定于这些属性的逻辑。实体不得具有处理不属于它们的对象的逻辑。

一个实体必须有办法唯一地识别它。这可以使用一组属性来完成，但更常见的是，一个名为“id”的人工属性将用于保存唯一的数字或字符串。

关联

对象之间的关联可以在数据库级别比较为表示对象的两个表之间的连接。在 OOP 级别，它可以被视为包含另一个对象或对象集合的对象，作为其属性之一。

为了保持代码简单和可维护，一个务实的规则是不创建也不保留死代码（未使用的代码）。关联通过代码反映在域的实现中。因此，将关联保持在域所需的最低限度是完全有意义的。这意味着尽管双向关联在通用上下文中可能有意义，但如果在我们的特定领域中它仅作为单向关联有意义，我们不能浪费时间和资源来创建不必要的代码。它不反映模型并增加了复杂性和可维护性成本。基本上它会使应用程序膨胀。

可以通过三种方式减少关联：

实施单向关联例如：我们可以说一个国家有很多位总统，而一位总统是特定国家的总统。这反映了双向关联，但是如果在我们的特定领域中我们总是根据“这个国家有这组总统”而不是“这个人是那个国家的总统”来思考，我们一定不能创建代码来支持第二个方向，因此强加了单向关联；添加限定符（过滤器）例如：如果在前面的单向关联中我们意识到在我们的特定领域中只有通过提供日期来查询国家总统才有意义，并且知道在特定日期只有一位总统，那么我们可以减少关联从单向 1-n 到单向 1-1。从而再次创建领域的更好反映并简化实施；消除不必要的联想如果某个关联在我们手头的特定领域没有用，则必须将其完全删除；服务

服务是表示流程的对象，而不是匿名值或具有自己的身份、数据和与该数据相关的功能的特定事物。

一项服务：

表示一个过程，一个或多个实体上的一系列动作；是无状态的，这意味着它不持有改变其行为的状态。因此它可以而且应该是单例；模块和包

模块也应该作为领域模型的一个有意义的部分出现。他们将一组功能、一个概念分组，并将其复杂性与其余领域模型模块和实现隔离开来。

与在单个对象中一样，模块之间的低耦合和模块内部的高内聚性很重要。

正如更小的代码单元随着领域得到更好的理解而发展一样，模块也会发生同样的情况，作为类，应该重构和重组以更好地反映领域模型并降低技术复杂性。

如果我们以模块之间的高耦合而告终，我们需要重新思考领域模型，澄清它，解开它，也许还会发现其他可能是新的或被忽视的概念。

选择能够讲述系统故事并包含一组内聚概念的模块。（第 110 页）

在构建应用程序时，技术实现应该是领域模型的反映。在实现域模型时，技术复杂性应仅次于概念清晰性。

如果开发人员理解模型所讲述的故事，他们就可以处理 [ … 技术复杂性 … ]。（第 111 页）

检测错误模块设计的代码异味是，当我们在一个模块中有一个类依赖于另一个模块中的类时，但这些模块似乎没有概念上的依赖性。在这种情况下，也许我们需要移动其中一个类，或者重新考虑实际的模块。

一个概念模块有几个高级包，即将一个概念分散到几个高级包中，会导致重构模块的难度增加。

支持这种代码模块/概念分散的一个论据是它在不同服务器中的部署。然而，通常情况并非如此。这种结构通常是在需要时才实施的，而这种对领域模型的掺假被证明是一种太大的牺牲。

除非真的打算在不同的服务器上分发代码，否则将实现单个概念对象的所有代码保留在同一个模块中，如果不是同一个对象的话。（第 115 页）

我们应该使用模块来封装领域概念，并在这个模块中使用包来封装架构层（应用程序、领域、基础设施……）。