【译文】一个设计精良的领域驱动模型的五个特征

查看原文

我在这篇博客文章中,我试图给领域模型下一个非常合适的定义,我发现我的这些定义都不太妥当,不过,我们还是可以先来看一下wiki百科对领域驱动模型下的定义:

问题解决和软件工程中的领域模型可以被认为是感兴趣的领域(通常称为问题领域)的概念模型,其描述了各种实体,它们的属性和关系,以及控制完整性的约束。包含该问题域的模型元素。

听起来很重要?换句话说,领域模型是每个应用程序的重要组成部分,它是现实世界概念的表示。但是,如何区分好的领域模型和坏的模型呢?由于了解领域模型,你也需要了解问题域,因此对于这个问题,并没有明确的答案。在这篇文章中,我打算通过介绍领域模型的五个特征来简化这个问题的理解难度。

我认为,一个好的领域模型,他应具备以下基本特征:

正确的对问题域进行建模。一个好的领域模型不一定是来自现实世界的精确副本,但它必须以所需的准确度对问题域进行建模。这意味着它必须仅包含与解决给定问题相关的信息。必须从域模型中排除不必要的信息,即使它存在于现实世界中。不过,仅仅包含正确的实体依然不够,这些实体之间关系也得正确。在你使用这个标准判断一个领域模型之前,你应当了解从问题域中发现的知识,这绝非易事。

使用正确的统一语言。由于领域模型是问题域的表示,因此必须正确地命名其元素、必须确保无论是客户或承包商都使用同一种语言(统一语言)。统一语言很重要,因为它可以最大限度地减少误解的可能性,而这些额外的误解可能降低向客户提供产品的质量。验证分析的域模型是否满足此要求非常简单,如果一个领域模型中的元素命名准确恰当,那么客户显然能无碍的理解。

领域应拥有和表达与当前问题域相关的完整信息。一个好的领域模型控制对其信息所做的更改。因此它应该提供操作其内容的方法,并禁止对其控制下的信息进行所有其他更改。仅为领域模型的信息提供单个访问点有两个主要优点:它减少了重复代码并保护了领域模型的完整性。因此,遵循此个方法将导致职责清晰且更不容易出错的代码,这应该是每个软件工程师的目标。此外,如果您需要仅基于领域模型且没有其他依赖关系的信息,则应将提供此信息的方法放在域模型中。这种方法遵循关注点分离原则,它将通过阐明软件的体系结构来提高代码质量。遵循这些方法也将帮助您避免称为贫血领域模型的反模式。

提供内置的日志记录支持。领域模型应该提供获取实体的内容序列化成字符串的方法,并把对象的内容写入到日志消息通常很有用。你不必手动构造日志消息,只需将有问题的对象输出到日志文件中,就足以让你了解到相关的操作过程。

良好的单元测试覆盖。良好领域模型的这种特征是显而易见的(至少对于专业人士而言),但我已经了解到假设可能是危险的。这就是为什么我想写下关于单元测试域模型的几句话的原因。虽然我知道精确的指导方针可能很危险,但我认为在这种情况下,可以为任何领域模型的单元测试提供准确的指导。您必须简单地测试每个方法(不包括getter或setter方法)。

通过本文作者描述了一个设计优良的领域模型的五个特征。通过这篇博文可以帮助读者辨识领域模型的优劣性,并为设计领域驱动模型提供一些提示。

PS:如果从头开始设计领域模型,往往会认为需要一个领域驱动设计的操作说明,因此作者推荐大家阅读 为Eric Evans的《Domain-Driven Design》,这是一本有关领域驱动设计的史诗级巨作,值得每一位开发者阅读。

原文地址:https://www.cnblogs.com/xiyuanMore/p/10836592.html

时间: 2024-10-10 14:28:49

【译文】一个设计精良的领域驱动模型的五个特征的相关文章

tornado项目之基于领域驱动模型架构设计的京东用户管理后台

本博文将一步步揭秘京东等大型网站的领域驱动模型,致力于让读者完全掌握这种网络架构中的“高富帅”. 一.预备知识: 1.接口: python中并没有类似java等其它语言中的接口类型,但是python中有抽象类和抽象方法.如果一个抽象类有抽象方法,那么继承它的子类必须实现抽象类的所有方法,因此,我们基于python的抽象类和抽象方法实现接口功能. 示例代码: from abc import ABCMeta from abc import abstractmethod #导入抽象方法 class F

【tornado】系列项目(二)基于领域驱动模型的区域后台管理+前端easyui实现

本项目是一个系列项目,最终的目的是开发出一个类似京东商城的网站.本文主要介绍后台管理中的区域管理,以及前端基于easyui插件的使用.本次增删改查因数据量少,因此采用模态对话框方式进行,关于数据量大采用跳转方式修改,详见博主后续博文. 后台界面展示: 地区管理包含省市县的管理.详见下文. 一.数据库设计 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 class Province(Base):  

领域驱动模型和以数据为中心模型的一些思考

假设有如下业务逻辑: 我要搬到新地方去工作. 代码1: class Player { public: void setAddr(string name); void setJob(string job); private: string _name; string _job; } 代码2: class Player { public: void changeAddr(string name); void changeJob(string job); private: string _name;

从零开始使用CodeArt实践最佳领域驱动开发(五)

本章内容还在整理上传中,你可以等全部更新完毕后再查阅也可以先预览已上传的内容...... 7. 应用层的命令模式 在上个章节里我们设计并编码了领域对象Permission,但是目前Permission并没有任何行为上的设计.这是因为我们不建议"凭空去制造行为",而是在领域对象第一个版本的代码实现之后就立即使用它.在使用过程中观察外界(应用层或其他领域对象)对它的需求,这些需求往往暗藏了进一步揭露对象本质特征的提示.我们可以根据这些提示逐渐挖掘出该对象更多的行为特征,结合CA里相关的设计

.NET领域驱动设计—实践(穿过迷雾走向光明)

阅读目录 开篇介绍 1.1示例介绍 (OnlineExamination在线考试系统介绍) 1.2分析.建模 (对真实业务进行分析.模型化) 1.2.1 用例分析 (提取系统的所有功能需求) 1.3系统设计.建模 (技术化业务模型) 1.3.1 枚举类型的使用 (别让枚举类型成为数值型对象) 1.3.2 基础数据.业务数据 (显示实体和隐式过程) 1.3.3 模型在数据库中的主外键关联问题 (面向对象模型与关系模型的天然抗阻) 1.3.4 角色.类型 (区分类型与面向对象概念) 1.3.5 名词

EntityFramework之领域驱动设计实践

EntityFramework之领域驱动设计实践 - 前言 EntityFramework之领域驱动设计实践 (一):从DataTable到EntityObject EntityFramework之领域驱动设计实践 (二):分层架构 EntityFramework之领域驱动设计实践 (三):案例:一个简易的销售系统 EntityFramework之领域驱动设计实践 (四):存储过程 - 领域驱动的反模式 EntityFramework之领域驱动设计实践 (五):聚合 EntityFramewor

Re:从零开始的领域驱动设计

领域驱动的火爆程度不用我赘述,但是即便其如此得耳熟能详,但大多数人对其的认识,还只是停留在知道它的缩写是DDD,知道它是一种软件思想,或者知道它和微服务有千丝万缕的关系.Eric Evans对DDD的诠释是那么地惜字如金,而我所认识的领域驱动设计的专家又都是行业中的资深前辈,他们擅长于对软件设计进行高屋建瓴的论述,如果没有丰富的互联网从业经验,是不能从他们的分享中获取太多的营养的,可以用曲高和寡来形容.1000个互联网从业者,100个懂微服务,10个人懂领域驱动设计. 可能有很多和我一样的读者,

领域驱动设计系列文章汇总

Entity Framework之领域驱动设计实践 EntityFramework之领域驱动设计实践 - 前言 EntityFramework之领域驱动设计实践 (一):从DataTable到EntityObject EntityFramework之领域驱动设计实践 (二):分层架构 EntityFramework之领域驱动设计实践 (三):案例:一个简易的销售系统 EntityFramework之领域驱动设计实践 (四):存储过程 - 领域驱动的反模式 EntityFramework之领域驱动

领域驱动设计(Domain Driven Design)参考架构详解

转自:http://blog.csdn.net/bluishglc/article/details/6681253 领域驱动设计(Domain Driven Design)参考架构详解 摘要 本文将介绍领域驱动设计(Domain Driven Design)的官方参考架构,该架构分成了Interfaces.Applications和Domain三层以及包含各类基础设施的Infrastructure.本文会对架构中一些重要组件和问题进行讨论,给出一些分析结论.本文原文连接:http://blog.