如何在EJB3.0架构下进行DDD实践。

如何在EJB3.O架构下来进行DDD实践，一般在项目中，我是这样做的:

表现层Action-->BusinessDelegate(业务委托)-->服务门面（session bean）-->domain object.

站在DDD的角度来说，应用层的服务可以通过有态或者无态的session bean来实现，在EJB3.0中提供了持久化服务，我们可以通过EntityManager对实体进行CRUD操作，现在的问题就是如何封装EntityManager。在Respository中封装可以吗？具体如何封装？如果采用JTA事务，无论会是CMT还是BMT，则Respository必然于EJB3.0架构产生了耦合，也就降低了领域模型的复用性。我们怎么样封装EntityManager才能做到即可以使用容器提供的持久化服务，又符合DDD实践要求呢？

Hibernate是JPA的超集，所以我们可以不用容器提供的持久化服务，自己通过Hibernate来实现，这样以来就容易通过Hibernate来实现Respository了，但是我觉得用EntityManager满方便的，所以想将EntityManager独立的封装起来，然后Resposity通过EntityManager和具体的数据库打交道，但是这样有个问题，如果采用JTA事务，那么Respostory也要通过EJB的组件来实现了，所以才有此种疑问，还请各位给点意见，多谢了。
[该贴被xmuzyu于2008-08-15 20:17修改过]

容器提供了分布式事务处理功能。如果集群的话用cmt吧
用ejb不能说耦合吧？那个是标准。
如果这都算的话那你就别用任何java代码了
(:

EJB确实是标准，但是还有其他的替代方案啊。我的意思是能在EJB和其他替代方案中平滑移植。如果仓库需要EntityManager提供持久化服务，那么势必造成了领域模型与具体的架构(比如EJB）产生了耦合。而领域模型应该是与具体的架构无关的。还请各位指点。

基本上可以认为EntityManager就是Repository+Factory

当然，EntityManager也可以脱离Session Bean测试和使用。

>领域模型应该是与具体的架构无关的
分析时是这样，但是落地实现时，其运行环境肯定和具体架构有关的。只要其对象内部没有和架构有关即可，领域模型是鱼，架构是水，事务也属于水环境。
[该贴被banq于2008-08-18 11:04修改过]

多谢banq老师指点。分析和设计确实还存在一定的不匹配之处，要想实现分析和设计的完美过渡还是需要经验积累的。