另外，我觉得你的经历和我以前说的很类似，为什么很多人觉得.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您是否有其他的考虑?请说一下您的看法!!!