jivejdon设计问题

09-03-11 yinyousong
              

个人认为,ForumThread,AccountProfile应该是ValueObject
值对象特征:
1.ValueObject是通过属性来比较的
2.它没有Identity
3.一创建即是最终状态
4.如果要修改ValueObject直接创建一个新的,而不是在原对象进行修改
5.不需要状态同步.

jiveJdon中ForumThread不可能独立存在,它必须依赖rootMessage(ForumMessage),而且是1:1的关系,要访问ForumThread必须通过ForumMessage,而且它的Identity是依赖rootMessage的(也就是说没用自己的Identity,并不是说在DB中它没主键).由于ForumThread,ForumMessage是1:1的关系,所以,任何时候获取同一个ForumMessage它说对应的ForumThread是相同的(即不需要状态同步)。
同理可得AccountProfile也是ValueObject

综上:ValueObject并不是不可以有Entity标识(DB主键),有Entity标识并不能说明它就是Entity(Domain Entity),具体应用具体分析.

以上纯属个人认识,如果有错误望大家指点.



[该贴被admin于2009-03-12 09:17修改过]

              

2
banq
2009-03-12 08:55

分析很深刻,同意ForumThread是值对象。这也是我后来逐步才认识到的,主要因为原来ForumThread有一个表,数据表概念影响了我,导致ForumThread和ForumMessage关系不紧密,导致一个BUG反复无法根除:就是在并发情况下,一个主题回帖后,这个主题thread不能及时更新其最新帖子的状态,这个问题单机测试是无法发现,一上线就出现,这从JiveJdon3.0和JiveJdon3.6版本不同比较中可以看出,我因为数据库思维影响也走了一段弯路,所以,现在才倡导不能太受数据库影响,最好的办法就是不学它,把它当作文件看到。

对业务需求进行类建模,从而知道了需求中的类和关联关系,类和关联在计算机运行是就是变成了内存中的对象和对象关系,电脑一关机,这些对象值和关联关系就没有了,所以,你必须保存对象值和关系到硬盘上,数据库不过就是这样一个持久化手段,如果把数据库看成对象值和关系的输出结果,就象人拉的屎一样,我们怎么能让屎来决定我们的脑袋呢?我经常这样脑袋好像被屎塞住一样。

相关帖:
对象在计算机生存空间:缓存
http://www.jdon.com/jivejdon/thread/35809.html
[该贴被banq于2009-03-12 16:56修改过]

saharabear
2009-03-12 17:27

sorry, I am doubt.

What is ForumThread and AccountProfile?

no matter these objects existed in DB or not, we do not care about the stat, just need some value. isn't it?

kylix_xp
2009-03-13 00:15

banq说的确实深有体会.数据表先入为主概念容易让领域建模误入歧途.面向数据库表的思维对现实世界进行抽象化和概念化比较困难.具体表现在我们的程序缺乏和现实世界领域的对应关系,对现实建模无能为力(或者是数据库建模对现实世界的模拟和映射并不自然和精确,因为数据建模无法映射现实业务实体抽象和具体,部分和整体的的关系,也无法映射业务实体与生俱来提供的行为和职责),建模就是将现实中的事务和计算机中的事务相互匹配和对应以及模拟,同时现实世界上是同时对数据以及对数据的操作是一个整体,而数据建模则没有.在实践中,我感觉到数据建模处理大型的异常复杂的业务是有些力不从心,前端表现层和后端耦合过紧,牵一发而动全身.数据建模解决了数学上的关系完整性的问题,却没有解决业务概念的完整性的问题(即不能完全模拟业务概念).
感觉到,jdon上面讲领域建模概念的和好处以及例子(如jivejdon)的很多.但是具体暴露建模的细节的这一思维过程的文章很少,也就是是说,如何去建模的文章太少(比如说如何去发现领域对象,如何发现领域对象的职责),希望banq以后多讲点儿建模过程的文章..呵呵
我个人觉得领域建模至少有以下几个步骤:
1.发现领域对象 方法有:领域的常识,前一个类似的系统抽取业务词汇 ,企业模型或供参照的体系结构 ,词汇表,报表,表单.一般可以通过名词语法分析来发现领域对象:这些名词一些是类,一些会成为类的属性,一些对我们的系统无关紧要 .每个名词或者形容词+名词的组合,我们把他们找出来,看哪些是我们候选的领域对象.一个常用的方法就是:用一些简单的问题来测试每个词.这个名词是否在系统的边界之内?这个名词可以拥有或者提供某些系统的服务或功能吗?这个名词拥有或者管理某些数据吗?这个名词和其它名词之间有什么关系吗?如果所有答案是"是",这个名词可能就是我们要找的领域对象.
2.弄清领域对象之间的关系 重点放在分析业务领域概念及其关系上,弄清领域对象的关系是:一般和特殊(继承),部分和整体(聚合和组合),还是关联和依赖等等
3.弄清领域对象的职责 CRC (类/职责/合作关系)方法 即通过基于角色的设计,通过角色的抽象和协作来弄清类的职责.即每个对象是一个角色,它对外提供什么服务,有什么职责,它维护和管理哪些信息,它和其他对象协作完成什么服务.CRC技术通过角色扮演的这种拟人的手法,以对话的形式模拟现实世界业务领域概念的行为,各种角色扮演不同的功能协作满足要实现的功能,是比较好的发现类的职责的方法.
4.弄清领域对象状态的变迁 使用UML状态图表示,如银行账户对象有正常,挂失,冻结,销户等状态.
5.领域对象相互协作提供服务 通过已有领域对象的组合和协作完成新的功能,领域对象的可重用性在此体现.
6.通过设计模式精化重构领域模型满足具体软件技术架构层次上的要求.
整个建模的思维过程就是一个探索复杂问题的过程,一个从模糊到清晰,从零散到系统的,从点到面的过程,从混沌到条理的逐步演进的过程.

[该贴被kylix_xp于2009-03-13 00:27修改过]
[该贴被kylix_xp于2009-03-13 00:28修改过]

pub
2009-03-13 11:26

这里有几个问题,在值对象中一直不明了。
1.值对象到底可以是组合多个对象的一个对象吗?
2.值对象存在的话它的好处和价值在哪里?
3.在DDD中除了domain对象就是值对象了吗?
-------------------------------------------
值对象的好处我认最大的就是共享。那么组合了多个对象的值对象类(如组合了创建时间这样的字段)那么共享基本不要想了。DDD的书中也讲了地址的例子,这是一个纯粹的值了。然后才是对象。
我再举个图片的例子。一个图片的内容是很少改的。但它他的上传时间等都是不一样的。有可能很多人上传了同一图片,那么这个图片是一个值对象。但它的上传时间可以组合到一个值对象吗?
其实threadcount它还是领域的概念,做为值对象很牵强。

从对象设计的原则来看。对象应该是最小的集合。那么domain object就可能聚合其它的对象是正常的。

7Go 1 2 3 4 ... 7 下一页