关于是否在.net项目中实施领域建模的困惑!

另外，我觉得你的经历和我以前说的很类似，为什么很多人觉得.NET简单，因为降低了设计标准，表面上.NET好像和Java平起平坐，其实内行人知道，如果不使用OO设计来实现，.NET充其量是披着华丽外表的旧躯体。相关帖子:

C就是Java只不过差了一点点:

http://www.jdon.com/jive/thread.jsp?forum=106&thread=14242

为什么Java不能象.NET那样可以掩人耳目呢？说实在，是可以的，但是最后这样做出来的系统性能很差，开发者没有从自身设计思维寻求原因，归结为Java解释型语言，大概语言本身就慢，等可笑原因。然后转往.NET，也许.NET容忍度比Java更大一些。（比如最近叫得欢的某个深圳金X软件，最早做J2EE服务器，后来转向.NET，现在又回来，这些都是很耐人寻味的）

所以，使用者素质和语言本身是一个相依相存的关系，抛开使用者也就是程序员素质，单单谈语言好坏，很显然是不符合基本逻辑的，现代软件不只是语言的飞跃变化，更重要的是设计思维变化，我们程序员要从传统过程思维迈上OO思维新台阶，然后再在新台阶新视野中对语言进行评头论足。

象楼主这样勇于自我挑战，不断进取的精神才是我们程序员应该学习的榜样，走出第一步很重要，尽管可能充满挑战，有J道支持，你们可以将设计开发过程疑问在这里讨论，共同进步。

[该贴被banq于2007年03月22日 10:58修改过]

因为现在项目还有有段时间才开始,所以我想研究一下合适的开源工具!

现在碰到的一些困惑有:

1.按照DDD书上的设计,DemainModel主要由三个模式来实现:aggregate, factory 和 repository.但是无论从spring.net+hibernate 还是您的jdon框架中,我都找不到这三种模式如何在框架中找到自己合适位置!那么,这三个基本模式对应到我们现在可用的架构中,应该如何实现和布局呢?

2.关于贫血模型.看到很多争论到底用贫血还是充血.其实按照DDD的设计,只要能把业务对象和业务逻辑清晰地与其他层隔离开,并保持良好的内聚应该就算达到要求!那么如果使用贫血模型,我们的业务逻辑是不是放在service层呢?如果这样的话,是不是又容易跟应用层的service相混淆,并且显的不OO了?

>是无论从spring.net+hibernate 还是您的jdon框架中,我都找不到这三种模式如

>何在框架中找到自己合适位置!

这些是在基于这些框架设计具体应用系统时可以看见，比如JiveJdon3中就可以看见，我还专门写了文章呢，如下：

实战DDD(Domain-Driven Design领域驱动设计)

http://www.jdon.com/mda/ddd.html

>只要能把业务对象和业务逻辑清晰地与其他层隔离开,并保持良好的内聚应该就算达到要求

完全正确，没有必要再争论贫血或嗜血问题，走极端了，象讨论吸血鬼一样，呵呵，说白了，这也是martion fowler惹的祸。

>么如果使用贫血模型,我们的业务逻辑是不是放在service层呢

当然不是了，而是放在Domain层，可以参考jivejdon3的Model包，Eric本人说了

，根据DDD, SOA再也不和OO矛盾了，因为Martin Fowler对SOA是翻白眼的，认为不OO（他是OO大师，可以自行解释OO了）。

服务也分领域层和应用层，而且应用层很少，可以见Jivejdon3的service包下，这些都是应用层service，但是你会发现service包下并没有包含真正业务逻辑，只是一个套,Shell，因为业务逻辑需要和计算机物理环境(如POOL Cache, DAO)等进行混合。

但是,好像banq在打包策略上有些复杂,也是导致我一开始没有找到正确实现的原因:

我有几个疑问:

1.在service包下面,正如您所说,除了ForumService以外其他都是领域service,但如果都放在同一个包下面,是不是容易造成混淆,我们的领域层服务和应用层服务都在一起,这样当需要扩展其他服务的时候也很容易把领域服务和应用层服务给混淆在一起?最终导致领域概念不能内聚?

2.Repositoy和factory都在repository包下面,但是他们的职责和用处都是不同的,能有更好的办法把它们分开吗?

3.Evans建议按照领域概念进行打包,那是否意味着同属一个业务范围里的实体/值对象,以及它们的factory/repository,还有这个概念领域的service都放在一个包里?

--假设我们想要将领域核心(包括模型和业务规则)移植到另一个框架(甚至平台)的时候,如果能准确地定位到所有领域核心概念的实现类,就可以只把整个Domain相关的包拿出来,从而实现领域核心的重用而不仅仅是代码片断的重用!

也许我的想法比较幼稚,目前估计要做到这一点估计不太可能.但是DDD的提出我想一方面可以应对领域本身的业务变化,另一个远见之处可能在于实现业务级核心的重用.

我们的技术不断在发展,各种应用层的工具也层出不穷,所以应用/UI/基础架构都是可以被替换的.但是一个行业的业务模式变化却相对稳定.

所以,如果能通过DDD的思想,把一个行业的核心概念以软件代码的方式进行精练和重用,也许能实现我们领域建模的终极目标吧?

--所以,对于打包的方法,我肤浅以为是应该将领域层的整个概念很好的封装起来,但是不知道banq您是否有其他的考虑?请说一下您的看法!!!

理解错了，service包下面都是应用service，领域层service在manager包或一些Model包下。

>Repositoy和factory都在repository包下面,但是他们的职责和用处都是不同的,能有更好的办法把它们分开吗?

按照Evans DDD,Repositoy和factory意思是非常靠近的，可以放在一起，当然也可以分开。

>Evans建议按照领域概念进行打包,就可以只把整个Domain相关的包拿出来,从而实

>现领域核心的重用而不仅仅是代码片断的重用!

这个概念是好的，这是为了达到业务重用，但是目前来说，这对Evans DDD这样MDD方法来说，要求太高了，重用应该看到实际是领域模型类图重用，这可以由MDA来完成。

以JiveJdon3来说，现在还是可以实现重用的，主要领域概念都在JiveJdon3的Model包下面，可以将Model包下面的拿出来重用，你可以下载JdonFramework的案例Sample下面有一个message应用，这个应用是一个政府办公OA简单应用，这个应用就是重用拷贝了JiveJdon3下面的Model包，你比较一下看看。

如何处理对象删除时引用的判断

http://www.jdon.com/jivejdon/thread/31249.html

感谢一下banq，提供这样一个平台让我找到一个可以交流的地方。

我毕业到现在一直从事.Net工作，最近却有了想转Java的念头了．的确，.NET里面很少有人谈OO.　他们更多的还是基于数据库，关注UI.

不过我到是孜孜不倦的在.Net里面学习OO技术，现在回想起来，真的很庆幸我在.NET里面没有放弃OO.

Java 世界更加关注的是设计思想,真想尽快转过来．

无论什么语言，如果没有思想，那真是华而不实的表面．

其实.NET里面也有很多优秀的开源项目，Castle就是我觉得最好的一个．

楼主如果还在.NET里面做，可以用 ASP.NET+ Caslte+ IBatisNet/NHibernate，

这个是我觉得在.NET里面最好的一个架构了．

可以实现IOC, 再加上 ASP.NET的快速开发,　是一个不比Struts+Spring+Hibernate差的架构．

--我跟abiandbel 正好相反,毕业后一直作java,上个项目是因为客户要求用.net,所以才被迫改行!

不过我觉得banq说的很好,设计是跟语言无关的.

所以,我并没有觉得在.net平台上进行设计锻炼有什么困难;

在.net氛围里,少了些自由思想,多了些对MS的依赖.我很庆幸以前是做java的,否则可能至今也不会产生到需要转向OO的迫切愿望!

不过比较好的是,现在.net领域已经逐渐有很多人都开始学习java社区里的相关概念,一些从java工具移植过来的工具也逐渐深入人心!

比如spring.net, NHibernate,Nunit,Castle,NAnt...

看来MS只能垄断产品,却不能垄断人的思想;有了这些工具,我们开发人员可以更专注于怎么制造高质量的软件,而不再受到技术和产品的限制;毕竟选择什么平台很大程度上是由客户和项目环境决定的,但只要练就了良好的OO基本功,我们就可以从技术平台的争论和局限中解脱出来,并从更高的角度来思考如何设计好软件.

希望与大家一起进步,共同学习!

--PS:banq能不能开一个.net板块,这样我们可以吸引更多.net平台的人讨论OO的工具和思想!

包括最简单的，你用vs做一个页面，它都自动遵循mvc的模式，只是它把这些东西隐藏的太好了，以致于你觉得它很简单。因为它把复杂的东西替你做了。

是否神秘在于你是否有心去研究。不能说因为感觉简单所以简单。

用JAVA或C还不是可以写得完全不OO。

观念没树立，想写好也难。

思想到了，就算用JavaScript也一样写得很OO。

那么楼上兄台认为谁写的oo比较好那？？

java与C是可以写的不能oo，不过样子好像必须oo

也想问一下楼上的oo的特性是什么，javascript具备这些特性么？

我的那个“一个小的WEB项目中的实现方法讨论”其实在有服务端的高手的支持下，也可以应用到大型web项目中去，说白了就是2套系统，一套前台运行在浏览器（可以Ajax也可以不Ajax），以javascript完成元数据的表现，一套后台运行在服务端，可以是jsp/asp/php。可能看起来复杂，不过服务端的数据处理和传输方面，可以保证是最小化的，不能再小了。有前辈已经完成这种方式了，可惜还联系不到。

现在有些Ajax应用框架，是把Ajax代码以类似Taglib的方式插入到后台去，在后台自动生成，是另一种思路。缺点是不能垮服务器平台。

(QQ:396686)