话题关于实体与值对象;其实有个很容易让人误会的地方就是这值对象。比如vo他也叫值对象但是确不同于此时我们谈到的领域模型中的值对象;这就容易误倒学习者。领域模型中的值对象定义为没有唯一性标识/比较独立的一个对象主要起到对某领域的描述性作用。这句话其实很难理解的。至少我理解了将近一周。现在的理解程度就是值对象也可以作为实体的属性存在,与其相同都是属于描述实体。也可以单独作为值对象。大多数情况下值对象是不变的。例如一条数据中我们很少去改变的某一些字段。这个字段是这类数据的共性描述,可用来描述这条数据对应的实体。把他作为值对象好处就是可以减少实体的属性是其更清晰,看ddd上说好象性能上也有优化。值对象往往都是实体中的某个属性。实体中的某个属性为对象时可以封装多个对自己的描述。降低了业务复杂度。不知道这性能优化在哪里。

如果没错的话好象只对ejb起到点优化作用。少了不少远程方法调用(get\set)把一些实体属性放到值对象中。通过对象序列化传输,一次传输了一个对象而不用多次get set 。

这里的VO和EJB的VO不一样的意思。

EJB的VO只是一个数据对象,这里VO是和具体Java技术无关的建模设计概念。

以前我们使用EJB,常常容易走上过程化编程习惯,围绕数据库编程,对象为数据服务,对象变成数据对象值对象。

在DDD中,实体Bean要为Domain Model服务,EJB2中实体bean非常不方便,需要Model重新写一遍,然后再做一个VO,而在EJB3中,可以完全实现依赖Domain Model,以Domain Model为核心的开发模式了。

>>>>根据Eric的理论,业务层将细分为两个层次:应用层和领域层。它们的定义是:应用层:定义软件可以完成的工作,并且指挥具有丰富含义的领域对象来解决问题,保持精练;不包括业务规则或知识,无业务情况的状态; 领域层:负责表示业务概念、业务状态的信息和业务规则,是业务软件核心。

翻译一下不知道对不对。业务层按代码包层次划分为 model 和 service
model为上述领域层 表示业务的概念,model的实例为业务状态信息, 业务规则是什么?
service为上述的应用层 表示软件可完成的工作也就是类中的方法,指挥领域对象则代表new 一个model实例或直接由上层传递过来一个model实例,对其操作解决业务问题。保持精练就是代码写好点用最少的优化过的代码解决问题就OK。无业务状态就是应用层的类不要有属性变量,无业务规则同样还不太了解。

如题所述 领域层对象就不能应用与单例模式,因为在多线程高并发时对象的状态有可能会被两个请求所共享导致不愿发生的事。
而如果按照DDD的最佳方案设计出的应用层设计规则,也就是其中无业务状态规则等。代表了应用层的服务可应用单例模式。就像IOC容器 HiveMind 默认的服务都是单例的。但如果把带有状态属性的bean也定义为一个service-point用hivemind的注入到某服务时 这样会出现问题,不应该把model设置成服务,那model的创建用什么好那?用时 new一个还是有其他更好的选择如工厂模式

这本书不太好看懂啊,语言不知道是怎么回事,就是读起来比较累

Domain-Driven Design这个东西其实早已经有了,而且大家多多少少都在用,只不过不知道理论的高度。好比一个人能用双腿走路,我们都觉得正常,直到学了物理才知道这是摩擦产生力的效果。我个人认为没有必要把一个理论搞得这么神话,让人觉得这是一个法宝,有了它什么都能解决。现在热吹的SOA,其实Microsoft的COM+就基本是这个概念了,由于当时的种种原因没有流行起来,现在在java这个阵营里热起来了,让人感觉好像是什么创举一样,在我看来,这些多少有用SOA这个名词来为各大厂商的产品做广告的嫌疑:SOA现在流行,作为Java Developer你都不知道SOA怎么混啊,我们XXX公司的XXX产品可以很好的实现SOA,快来学习吧。早年IBM力推的MDA,还有曾经出现的FDD,也像现在的SOA一样被大家疯狂追捧,不是吗?我要说的是,不要把这种浮在表面的东西看得那么重要,作为一个Developer,甚至是一个Architect,这些无非是一些吹牛的玩意儿,并不能为具体的工作带来实质性的成果,老老实实的学习些基本的东西才是实在的。经常把这些挂在嘴边的人,不是什么实干事情的人,他们是技术作者,纯研究人员,最多的还是软件的销售工程师,没有这些新名字,他们如何来推销产品呢?

说了这么多不好的,也来说点好听的。Domain-Driven Design,是种方法哈,好在哪里,我认为是解决了沟通的问题。我没有理论的高度,只说一个切身体会:需求分析人员将采集的来得需求做成一个个的用例或者是Story,这些用例描述一些典型的行为动作和预期的结果,而开发设计人员对用例的集合进行综合分析产生了对象模型和数据模型。bang所说的阻抗就是这里了,到这个阶段后,需求分析人员与开发设计人员对一些用例有了明显的不同认识,沟通出现了问题,比如从开发设计角度看,一些用例是有共性的,可以抽象统一起来,而需求分析人员认为这是两个功能模块不能混为一谈,是什么造成了这种沟通的不畅呢?我认为是大家失去了可以用于交流的共同语言,Domain Model是这种语言的基础,基于Domain Model建立的活动图(或者其他什么图都好)是语言,有了这些东西,让需求人员与开发人员联系的更为紧密,也能更好的确保软件的质量和开发进度。

还有一点,是我想说的,Domain-Driven Design不能取代OO Design,也不能取代Database Schema Design,Data Model是基本,OO model和Data Model是不同的表现形式,希望有的兄弟不要想歪了。

买股票,看着大盘猛涨就跟着吃进,总这么干不赔才怪。跟风是要不得的,不希望所有中国的兄弟们被洋鬼子和假洋鬼子们忽悠了。

“不要把这种浮在表面的东西看得那么重要,作为一个Developer,甚至是一个Architect,这些无非是一些吹牛的玩意儿,并不能为具体的工作带来实质性的成果,老老实实的学习些基本的东西才是实在的。
跟风是要不得的,不希望所有中国的兄弟们被洋鬼子和假洋鬼子们忽悠了。”

samepoint兄真是老经验了。本人跟风跟了三年,吃尽了苦头。最近好好重新啃了啃TIJ、Effective Java,这才感觉重新回到了正路。
[该贴被lgx522于2007年05月18日 14:59修改过]

今天这D明天那D,MDD出来那么多年,今天又看到了一会
到底是为了什么而D

很不错

专业驱动设计,你们的ddd,不就是对service层,再细化分层吗?搞的好像发现曹操墓似的~~~~~
另外这是搞培训的,得防忽悠~~~。真的希望中国的java社区能够静下心来,引用别人的话(个人觉得确实有些道理的):

或许真的如朋友笑谈,java 封装和统一了太多东西,导致程序员的智慧无初发挥,只能集中到设计模式上发泄了 :) 而 C++ ,却有无数的方法证明你的聪明。

另一个例子也很恰当:如果在 java 社区,宣布了一向新特性,会使整个社区的开发效率明显提高,即使这个特性会使世界上所有的 java 程序效率损失 10% 。大多数 java 程序员还是会拍手称快。反正 java 在运行效率上的名声已经臭名招著了,大家也不再在乎。而换到 C++ 社区,即使这个新特性只有 0.1% 而不是 0 的性能损失,必然招至一片唾骂声,吵上10年也不可能写进 ISO 标准。在效率问题上,java 程序员更加指望那些为他们写虚拟机的人做出新的发明,然后发布一个报告,谈即新的技术可以使 java 程序运行速度加快即可。

不得不说,C++ 和 java 是在两个层次上的语言。一个从机器模型延续而来,一丝一环紧紧相扣。而 java 语言却从机器层面向上一跃,中间留下一个空挡。阻止程序员去跨越。这使整个社区的人力集中于更高的层面,未尝不是一件好事啊。

个人比较欣赏网易云风的kiss原则,人家可是大牛^_^,赞同 samepoint 的观点

[该贴被tdd于2010-01-05 02:32修改过]
[该贴被tdd于2010-01-05 02:47修改过]