前言 哈喽,老张是周四放松又开始了,这些天的工作真的是繁重,三个项目同时启动,没办法,只能在深夜写文章了,现在时间的周四凌晨,白天上班已经没有时间开始写文章了,希望看到文章的小伙伴,能给个辛苦赞

其他博文: DDD 领域驱动设计-三个问题思考实体和值对象 DDD 领域驱动设计-三个问题思考实体和值对象(续) 以下内容属于博主"臆想",如有不当,请别当真. 扯淡开始: 诺兰的最新电影<星际穿越>,最近非常的火热,每个人看完之后都会有不一样的感受,黑洞.虫洞.时间旅行.相对论.未来.人类.爱等等,这些都是这部电影的关键词,科学和艺术原来还可以这样子结合,真是令人叹服.网上有很多人去写一些东西进行分析探讨,也引发了全球"科学热",这些都是好电影所蕴含的

上一篇:DDD 领域驱动设计-三个问题思考实体和值对象 说实话,整理现在这一篇博文的想法,在上一篇发布出来的时候就有了,但到现在才动起笔来,而且写之前又反复读了上一篇博文的内容及评论,然后去收集资料,真正去写的时候,才发现这类的博文真不是一般的难写,一句话要反复揣摩,并进行理解,最重要的是半天才蹦出一句话. 看了上面的文字,你可能会觉得我是为了写博文而写博文,其实并不是如此,我现在觉得写这类博文的目的在于梳理自己的观点,然后再进行表达出来,有的人可能会觉得为什么要纠结某一类观点?或者认为陷在一个

消息场景:用户 A 发送一个消息给用户 B,用户 B 回复一个消息给用户 A... 现有设计:消息设计为实体并为聚合根,发件人.收件人设计为值对象. 三个问题: 实体最重要的特性是什么? Message 实体是怎么得来的? 发件人.收件人为什么不是实体? 1. 实体最重要的特性是什么? <领域驱动设计>5.2 实体: 摘录一段:许多对象不是由它们的属性来定义,而是通过一系列的连续性(continuity)和标识(identity)来从根本上定义的. 归纳: 标识(identity) 连续性(c

一.简要介绍 ABP vNext 框架本身就是围绕着 DDD 理念进行设计的,所以在 DDD 里面我们能够见到的实体.仓储.值对象.领域服务,ABP vNext 框架都为我们进行了实现,这些基础设施都存放在 Volo.Abp.Ddd.Domain 项目当中. 本篇文章将会侧重于理论讲解,但也只是一个抛砖引玉的作用,关于 DDD 相关的知识可以阅读 Eric Evans 所编写的 <领域驱动设计:软件核心复杂性应对之道>. PS: 该书也是目前我正在阅读的 DDD 理论书籍,因为基于 DDD 理

图中是一个别墅的模型,代表实体,可以真实的看得到.那么在DDD设计方法论中,实体和值对象是什么呢? 背景 实体和值对象是领域模型中的领域对象,是组成领域模型的基础单元,一起实现实体最基本的核心领域逻辑. 那么问题来了: 1, 他两在领域模型中的作用是什么? 2,在系统中跟代码模型和数据模型是怎么对应的? 搞清楚这两个问题很重要.回答问题是需要有知识基础的,先来捋清楚这两个概念的定义和内涵.然后在小结部分我们来回答这两个问题. 实体 定义: DDD中的一类对象,拥有唯一标识符,经历各种状态变更后仍

1.      聚合根.实体.值对象的区别? 从标识的角度: 聚合根具有全局的唯一标识,而实体只有在聚合内部有唯一的本地标识,值对象没有唯一标识,不存在这个值对象或那个值对象的说法: 从是否只读的角度: 聚合根除了唯一标识外,其他所有状态信息都理论上可变:实体是可变的:值对象是只读的: 从生命周期的角度: 聚合根有独立的生命周期,实体的生命周期从属于其所属的聚合,实体完全由其所属的聚合根负责管理维护:值对象无生命周期可言,因为只是一个值: 2.      聚合根.实体.值对象对象之间如何建立关联

1.内容摘要 最近在看DDD领域驱动设计,看到实体(Entity),值对象 (Value Object),以及聚合根(Aggregate Root) 时.对他们的关系有些模糊,不清楚.于是去找了找资料,看到有篇文章写的挺好的,于是分享出来给大家. 2.文章来源 http://www.cnblogs.com/netfocus/archive/2012/02/12/2347938.html 博客园用户名 :netfocus [ http://www.cnblogs.com/netfocus/ ] 3

原文:DDD中的值对象如何用NHibernate进行映射 <component/>是NHibernate中一个有趣的特性,即是用来映射DDD(Data-Display-Debuger)概念形式的值类型.这是一种创建比物理数据模型具有更高粒度的对象模型的方式.  举例,   看下表中的数据:    对应的对象模型:    它们十分不同,在一个单一表中包括了所有物理数据,我们想在对象模型中调整为用两个分离的类型来映射该表.这就是<component/>的用法:  <class n

关于具体需求,请看前面的博文:DDD领域驱动设计实践篇之如何提取模型,下面是具体的实体.聚合.值对象的代码,不想多说什么是实体.聚合等概念,相信理论的东西大家已经知晓了.本人对DDD表示好奇,没有在真正项目实践过,甚至也没有看过真正的DDD实践的项目源码,处于极度纠结状态,甚至无法自拔,所以告诫DDD爱好者们,如果要在项目里面实践DDD,除非你对实体建模和领域职责非常了解(很多时候会纠结一些逻辑放哪里好,属于设计问题)以及你的团队水平都比较高认同DDD,否则请慎重...勿喷! 代码在后,请先看D

这里的值对象如下风格: namespace Order.Domain.PocoModels { //订单地址 //虽然是值对象 但是不继承ValueObject //因为继承ValueObject会有Id属性 我们不为它创建独立建表不要Id public partial class OrderAdress { public string Province { get; set; } public string City { get; set; } public string Zero { get

1 前置阅读 在阅读本文章之前,你可以先阅读: 什么是DDD 2 实现值对象 值对象有两个主要特征:它们没有任何标识.它们是不可变的. 我们举个例子:小明是"浙江宁波"人,小红也是"浙江宁波"人,小王是"浙江杭州"人,在这个例子中,我们把地址可以独立出一个值对象出来,我们会遇到了多个对象是否相同的问题,例如小明和小红的地址应该是相等,小明和小王应该是不相等,这很好理解,我们来看一下例子: public class Address { public

阅读目录 前言 场景1的思考 场景2的思考 避坑方式 实践 结语 一.前言 在上一篇中(如何一步一步用DDD设计一个电商网站(八)—— 会员价的集成),有一行注释的代码: public interface IRoleDiscountRelationRepository// : IRepository<RoleDiscountRelation> { RoleDiscountRelation Get(string roleId); } 其中涉及的到问题是关于值对象的持久化问题.是的,由于我们之前的

前面介绍了DDD分层架构的实体,并完成了实体层超类型的开发,同时提供了验证方面的支持.本篇将介绍另一个重要的构造块——值对象,它是聚合中的主要成分. 如果说你已经在使用DDD分层架构,但你却从来没有使用过值对象,这毫不奇怪,因为多年来养成的数据建模思维已经牢牢把你禁锢,以致于你在使用面向对象方式进行开发时,还是以数据为中心. 当我们完成了基本的需求分析以后,如果说需要进行设计,那么你能想到的就是数据库表及表关系的设计,这就是数据建模.数据建模的主要依据是数据库范式设计,根据要求严格程度的递增分为

DDD分层架构之值对象(介绍篇) 前面介绍了DDD分层架构的实体,并完成了实体层超类型的开发,同时提供了验证方面的支持.本篇将介绍另一个重要的构造块——值对象,它是聚合中的主要成分. 如果说你已经在使用DDD分层架构,但你却从来没有使用过值对象,这毫不奇怪,因为多年来养成的数据建模思维已经牢牢把你禁锢,以致于你在使用面向对象方式进行开发时,还是以数据为中心. 当我们完成了基本的需求分析以后,如果说需要进行设计,那么你能想到的就是数据库表及表关系的设计,这就是数据建模.数据建模的主要依据是数据库范

DDD理论学习系列--案例及目录 1.引言 提到值对象,我们可能立马就想到值类型和引用类型.而在C#中,值类型的代表是strut和enum,引用类型的代表是class.interface.delegate等.值类型和引用类型的区别,大家肯定都知道,值类型分配在栈上,引用类型分配在堆上. 那是不是值类型对应的就是值对象,引用类型对应的就是实体吗?很抱歉,不是的. 值对象我们要分开来看,其包含两个词:值和对象.值是什么?比如,数字(1.2.3.14),字符串("hello world".&

实体值对象的含义 我们前面已经讲过领域的概念, 今天来讲讲实体, 实体是我们进行设计领域模型时的基础单元, 与之有关的是值对象, 接下来先梳理一下实体以及值对象的含义,然后讲讲他们俩的关系, 希望通过这篇文章能让你区分开与传统架构中实体的区别, 对领域模型中的实体有进一步的了解. 实体 实体这个概念在传统微服务中也有涉及, 在传统技术中, 实体一般是指实体类, 也就是数据库中的表格, 但是在领域模型中实体与传统架构中的实体有类似的地方但是不完全一样, 在DDD中, 实体的定义是: 实体拥有唯一标

上一篇介绍了值对象的基本概念,得到了一些朋友的支持,另外也有一些朋友提出了不同意见.这其实是很自然的事情,设计本来就充满了各种可能性,没有绝对正确的做法,只有更好的实践.但是设计与实践的好与坏,对于不同的人,以及处于不同的环境都有不同的诠释,这是一个仁者见仁,智者见智的问题.DDD非常抽象,以至于它的每一个概念,对于不同的人都有不同的看法,更何况基于DDD的.Net实践,就更难分辨哪一个用法更标准.更正宗. 我对DDD的认识虽然还很肤浅,用得也很山寨,但这可能更加适合初步接触DDD的朋友.还是那

回到目录 注意,这里说的值对象是指在MongoDB实体类中的,并不是DDD中的值对象,不过,两者也是联系,就是它是对类的补充,自己本身没有存在的价值,而在值对象中,也是不需要有主键Id的,这与DDD也是不谋而合的,也是可以理解的,因为它只是对主对象的一种补充说明,自己不存在任何意义,所以要主键也没什么用,呵呵. 看一个MongoDB的值对象contact public class Person { public Person() { Contact = new Test.Contact(); A

DDD分层架构之值对象(层超类型篇) 上一篇介绍了值对象的基本概念,得到了一些朋友的支持,另外也有一些朋友提出了不同意见.这其实是很自然的事情,设计本来就充满了各种可能性,没有绝对正确的做法,只有更好的实践.但是设计与实践的好与坏,对于不同的人,以及处于不同的环境都有不同的诠释,这是一个仁者见仁,智者见智的问题.DDD非常抽象,以至于它的每一个概念,对于不同的人都有不同的看法,更何况基于DDD的.Net实践,就更难分辨哪一个用法更标准.更正宗. 我对DDD的认识虽然还很肤浅,用得也很山寨,但这可