>们可以把业务逻辑放在实体中，而这时候的实体，我们可以理解为domain object.而让我们的session >bean和MDB只是协调实体来完成任务，只是作为实体的控制器，也就是让bean做为service

正确 ，无论EJB3.0/2.0都是这种思路，有人提出：在EJB中Domain Model设计需要失血贫血模型，因为这样可以在多个服务器之间方便传输，如果都将业务行为放入Domain Model，Model臃肿，在分布式共享下序列化Model性能会很低。所以，失血贫血模式有益处。

我不认同这种这种从分布式/SOA角度支持贫血模式的观点，我认为没有必要搞形式代码上的充血，充血模式一个大概念，它可以包含很多代码类的实现，而且从OO设计原则来说，我们也不可能让所有业务行为都充到一个Model中去，我们必须通过设计模式来对这个臃肿的Model进行分解细分，比如桥模式。这里也反应分析和设计确实存在一些难以逾越的鸿沟。

有人看到JiveJdon3中FourmMessage只有set/get，就认为是贫血的，这就很片面，不能教条主义看待失血和充血，JiveJdon3的ForumMessage粗看上去是失血，只有set/get，没有业务逻辑，但是看看其子包下MessagRender就发现业务行为不少，这些都是从FourmMessage中分离出来的，是细节设计考虑，当然如果为了面对形式上充血，我完全可以将MessageRender功能都并入ForumMessage，那谁能看得懂ForumMessage呢？OO宗旨又跑到哪里了呢？再说Evans DDD最终必须结合设计模式的。

通过我这样的思路，我们的Domain Model又是充血的丰富的，完整的，又能够在分布式系统/SOA中快速序列化奔跑，这就是裸奔，裸奔有理，体现我们OO分离细分原则。

[该贴被banq于2008-06-14 10:05修改过]

多谢banq老师和freebox.<<uml和模式应用>>里面讲了很多面向对象的设计原则（GRASP原则）,这些原则告诉我们如何给对象分配职责，具体到DDD里，就是如何给我们的Domain object分配职责。正如banq老师所说的：
>>>>有人看到JiveJdon3中FourmMessage只有set/get，就认为是贫血的，这就很片面，不能教条主义看待失血和充血，JiveJdon3的ForumMessage粗看上去是失血，只有set/get，没有业务逻辑，但是看看其子包下MessagRender就发现业务行为不少，这些都是从FourmMessage中分离出来的，是细节设计考虑，当然如果为了面对形式上充血，我完全可以将MessageRender功能都并入ForumMessage，那谁能看得懂ForumMessage呢？OO宗旨又跑到哪里了呢？再说Evans DDD最终必须结合设计模式的。

确实是表面上贫血，实际上充血，这是符合高内聚，低耦合原则的。

[该贴被xmuzyu于2008-06-16 01:35修改过]

>>领域层服务容易和领域模型行为，很多人容易把领域模型行为也就是业务核心放入领域层服务中，我前面讨论的就是这种情况，虽然领域层服务控制了领域模型，但是不代表业务核心就要放入领域层服务，而应该放入领域模型中，这两者区别也有些鱼和水的区别，服务是SOA等架构，而领域模型则应该和架构无关，只和业务有关，脱离当前架构SOA也可以生存，比如移植到EDA架构也应该可以，如果你到EDA下，由于没有Service，而你的业务核心在Service，那你不是要重写软件了？

--老师，关于领域模型的行为与领域层的服务，可不可以这样理解？比如，某个人是一个实体，然而把他放在比如IT行业领域中，他是个软件工程，那个这个领域模型就是软件工程师他了。那个领域模型中的业务核心就是人的基本功能和领域模型的功能如，人会吃饭，走路还有软件工程师会开发软件等。那么领域服务是什么呢？我想就是为操作这个软件工程师所做的操作，比如要这个软件工程师做哪方面的开发等。就像老师说的请假条是领域模型，那么各部门是service一样，或者请假条有其自己的功能，这些就是其业务核心，那么这个请假条拿到哪里都可以复用，而service并不一定能复用，因为他们可能只适合于某领域。那这些service就是对请假条这个领域模型作操作的。

看不懂