作者在这篇博客文章中，试图给领域模型下一个非常合适的定义，但是发现这些定义都不太妥当，不过，我们还是可以先来看一下wiki百科对领域驱动模型下的定义：
问题解决和软件工程中的领域模型可以被认为是感兴趣的领域（通常称为问题领域）的概念模型，其描述了各种实体，它们的属性和关系，以及控制完整性的约束。包含该问题域的模型元素。
听起来很重要？换句话说，领域模型是每个应用程序的重要组成部分，它是现实世界概念的表示。但是，如何区分好的领域模型和坏的模型呢？由于了解领域模型，你也需要了解问题域，因此对于这个问题，并没有明确的答案。在这篇文章中，我打算通过介绍领域模型的五个特征来简化这个问题的理解难度。
我认为，一个好的领域模型，他应具备以下基本特征：
正确的对问题域进行建模。一个好的领域模型不一定是来自现实世界的精确副本，但它必须以所需的准确度对问题域进行建模。这意味着它必须仅包含与解决给定问题相关的信息。必须从域模型中排除不必要的信息，即使它存在于现实世界中。不过，仅仅包含正确的实体依然不够，这些实体之间关系也得正确。在你使用这个标准判断一个领域模型之前，你应当了解从问题域中发现的知识，这绝非易事。
使用正确的统一语言。由于领域模型是问题域的表示，因此必须正确地命名其元素、必须确保无论是客户或承包商都使用同一种语言（统一语言）。统一语言很重要，因为它可以最大限度地减少误解的可能性，而这些额外的误解可能降低向客户提供产品的质量。验证分析的域模型是否满足此要求非常简单，如果一个领域模型中的元素命名准确恰当，那么客户显然能无碍的理解。
领域应拥有和表达与当前问题域相关的完整信息。一个好的领域模型控制对其信息所做的更改。因此它应该提供操作其内容的方法，并禁止对其控制下的信息进行所有其他更改。仅为领域模型的信息提供单个访问点有两个主要优点：它减少了重复代码并保护了领域模型的完整性。因此，遵循此个方法将导致职责清晰且更不容易出错的代码，这应该是每个软件工程师的目标。此外，如果您需要仅基于领域模型且没有其他依赖关系的信息，则应将提供此信息的方法放在域模型中。这种方法遵循关注点分离原则，它将通过阐明软件的体系结构来提高代码质量。遵循这些方法也将帮助您避免称为贫血领域模型的反模式。
提供内置的日志记录支持。领域模型应该提供获取实体的内容序列化成字符串的方法，并通过把对象的内容写入到日志的做法通常很有用。采用这种方法你不必手动构造日志的结构，只需将有问题的对象输出到日志文件中，就足以让你了解到相关的操作过程。
良好的单元测试覆盖。设计一个好的领域模型，单元测试覆盖率显然是必须考虑的因素（至少对于专业开发者而言）。不过对于读者来说，可能为每个领域编写单元测试或许会有点危险。这就是为什么我想写下关于单元测试领域模型的几句话的原因。即便如此，作者认为在这种情况下，为了能够给任何领域模型的单元测试提供准确的指导，您必须以最简单的方式测试每个方法（不包括getter或setter方法）。
通过本文作者描述了一个设计优良的领域模型的五个特征。通过这篇博文可以帮助读者辨识领域模型的优劣性，并为设计领域驱动模型提供一些提示。
PS：如果从头开始设计领域模型，往往会认为需要一个领域驱动设计的操作说明，因此作者推荐大家阅读 为Eric Evans的《Domain-Driven Design》，这是一本有关领域驱动设计的史诗级巨作，值得每一位开发者阅读。
作者说这篇写于8年前的文章，现在他回顾起来觉得写得比较笨拙，他认为读者不应该过多的关注这篇文章给出的建议。