学习领域驱动设计(三)之实体

前一篇文章:"学习领域驱动设计(二)之上下文映射图及架构"给大家主要介绍了上下文映射图的概念,以及粗略的简介了在领域驱动设计中主要使用到架构知识,而这篇文章主要来学习在领域驱动中实体的作用。

当我们在考虑一个对象的个性特征,或者需要区分不同的对象时,我们需要引入实体的概念。

一个实体是一个唯一的东西,并且可以在相当长的时间内持续发生变化。我们可以对实体进行多次修改,故实体对象可能和它先前的状态不大相同。但是,由于它们拥有相同的身份标识(Identity),它们依然是同一个实体。

唯一的身份标识和可变性是实体对象与值对象的根本区别

本章的最终目的:如何正确地使用和设计实体

1.唯一标识

在设计实体时,我们首先需要考虑实体的本质特征,而不是一开始便关注实体的属性和行为。找到能够实现唯一标识性的方式,同时还要考虑如何在实体的生命周期内维持它的唯一性。

唯一标识用于实体实体匹配通常取决于标识的可读性。

1.1生成唯一标识的方式

1.用户提供唯一的标识

让用户手动输入对象标识看起来是一种很直接的做法,但是这种方式也可能变得很复杂。复杂性在于:1.需要用户自己生成高质量的标识,有可能输入的标识是唯一性,但也有可能是不正确的。

2.应用程序生成唯一标识

有很多可靠的方法都可以自动生成唯一标识,但是如果应用程序处于集群环境或者分布在不同的计算节点,我们就需要小心。以下方式可以生成1.计算机节点的当前时间,以毫秒记 2.计算机节点的IP地址 3.GUID

3.持久化机制生成唯一标识

4.另一个限界上下文提供唯一标识

5.委派标识

委派标识说白点就是数据库的自增主键,利用自增主键的特性生成唯一标识。在开发过程中我们大多应用场景都是采用这个方式来生成唯一标识来关联实体。

1.2发现实体及本质特征

1.2.1角色和职责

建模的一个方面是发现对象的角色和职责,通常来说,对角色和职责分析师可以应用在领域对象上。

领域对象扮演多种角色

在面向对象编程中,通常由接口来定义实现类的角色。在正确的设计的情况下,一个类对于每一个它所实现的接口来说,都存在一种角色。如果一个类没有显式的角色即该类没有实现任何显式接口,则默认情况下,它扮演的是本来的角色。

Public interface User{}//User对象

User类没有实现任何接口,但是它仍然扮演的是User角色。

1.2.2 验证

验证的主要目的在于检查模型的正确性,检查的对象可以是某个属性,也可以是整个对象,甚至是多个对象的组合。

1.验证属性,在C#中又称契约验证

2.验证整体对象

有时候实体中的所有单个的属性都是合法的,但是并不意味着整个实体就是合法的。要验证整个实体,我们需要访问整个对象的状态即所有对象的属性

3.验证对象组合

在需要对复杂对象进行验证时,我们可以使用延迟验证。因为有时候我们关注的并不是单独的实体的是否合法,还需要关注多个实体的组合是否合法。

时间: 2024-10-26 06:12:32

学习领域驱动设计(三)之实体的相关文章

学习领域驱动设计(二)之上下文映射图及架构

前一篇文章 :"学习领域驱动设计开篇"给大家主要了解了下领域驱动设计是什么!这篇文章主要介绍下上下文映射图及架构相关方面的知识. 1.上下文映射图 1.1上下文映射图为何如此重要 当项目中开始采用DDD时,首先你应该为当前的项目绘制一个上下文映射图,该图主要描述当前项目中的限界上下文之间的集成关系!而上下文映射图的作用就是帮助我们从解决方案空间的角度来看待问题.(限界上下文已在上篇文章中介绍了) U表示上游(Upstream).D表示下游(Downstream) 1.2绘制上下文映射图

EntityFramework之领域驱动设计实践

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

C#进阶系列——DDD领域驱动设计初探(一)

前言:又有差不多半个月没写点什么了,感觉这样很对不起自己似的.今天看到一篇博文里面写道:越是忙人越有时间写博客.呵呵,似乎有点道理,博主为了证明自己也是忙人,这不就来学习下DDD这么一个听上去高大上的东西.前面介绍了下MEF和AOP的相关知识,后面打算分享Automapper.仓储模式.WCF等东西的,可是每次准备动手写点什么的时候,就被要写的Demo难住了,比如仓储模式,使用过它的朋友应该知道,如果你的项目不是按照DDD的架构而引入仓储的设计,那么会让它变得很“鸡肋”,用不好就会十分痛苦,之前

初探领域驱动设计(1)为复杂业务而生

概述 领域驱动设计也就是3D(Domain-Driven Design)已经有了10年的历史,我相信很多人或多或都都听说过这个名词,但是有多少人真正懂得如何去运用它,或者把它运用好呢?于是有人说,DDD和TDD这些玩意是一些形而上的东西,只是一茶余饭后的谈资,又或是放到简历上提升逼格而已.前面这句话我写完之后犹豫了,犹豫要不要把它删掉,因为它让我看起来像个喷子,我确实感到不解,为什么别人10年前创造总结出来的东西,我们在10年之后对它的理解还处于这么低的一个层次.开篇就说远了,我也是最近才开始认

(转)EntityFramework之领域驱动设计实践

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

DDD领域驱动设计初探(一):聚合

前言:又有差不多半个月没写点什么了,感觉这样很对不起自己似的.今天看到一篇博文里面写道:越是忙人越有时间写博客.呵呵,似乎有点道理,博主为了证明自己也是忙人,这不就来学习下DDD这么一个听上去高大上的东西.前面介绍了下MEF和AOP的相关知识,后面打算分享Automapper.仓储模式.WCF等东西的,可是每次准备动手写点什么的时候,就被要写的Demo难住了,比如仓储模式,使用过它的朋友应该知道,如果你的项目不是按照DDD的架构而引入仓储的设计,那么会让它变得很“鸡肋”,用不好就会十分痛苦,之前

微服务架构设计基础之领域驱动设计

DDD早于微服务「出道」十年,这两个「忘年交」的软件设计哲学是如何相爱相杀的? 背景 微服务现在可以说是软件研发领域无人不提的话题,然而业界流行的对比多数都是所谓的Monolithic(单体应用),而大量的系统在十几年前都已经是以SOA(面向服务架构)为基础的分布式系统了,那么微服务作为新的架构标准与SOA有什么差异点呢?其本质区别在于设计原理,微服务是去中心化设计,SOA是「集成」形成中心设计: 另外,笔者认为以下几点并不是微服务和SOA的区别点: CI/CD:持续集成.持续部署本身与敏捷.D

分享我对领域驱动设计(DDD)的学习成果

本文内容提要: 1. 领域驱动设计之领域模型 2. 为什么建立一个领域模型是重要的 3. 领域通用语言(Ubiquitous Language) 4.将领域模型转换为代码实现的最佳实践 5. 领域建模时思考问题的角度 6.领域驱动设计的标准分层架构 7. 领域驱动设计过程中使用的模式 关联的设计 实体(Entity) 值对象(Value Object) 领域服务(Domain Service) 聚合及聚合根(Aggregate,Aggregate Root) 工厂(Factory) 仓储(Rep

领域驱动设计系列:三种领域逻辑组织模式的本质

企业应用架构模式中明确提出了三种领域逻辑组织模式:事务脚本.领域模型和表模块.不少人看的云里雾里的,不少人说的似懂非懂的,主要原因是没有从项目的级别的分析和设计经验,只有单个项目模块的开发经验的人很难理解到位. 1.事务脚本: 事务脚本的理解其实最简单,但是很多人说不清,觉得比领域模型还难理解,也对应不到代码.但这只是幻觉,怎么可能最简单的领域逻辑模式都不懂,反而对最复杂的领域模型模式懂了呢. 我们看企业应用架构模式中强调的一句话"使用过程来组织领域逻辑",其实事务脚本就是从过程的角度