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