请教，我的架构如此分层，不知合不合理

如果考虑采用DDD方法，那么JSF的managed Bean和Spring的bean就应该是同一个类型 Domain Model。

DDD和架构关系是：
先有DDD，再根据DDD来选择架构，越靠近DDD的架构越好，目前靠近DDD的有RoR，当然不忘推销本人的JdonFramework,而Spring则不是一个DDD框架。

谢谢，banq大侠。
我原先是想采用DDD方法，把域模型建立起来，然后因为域模型里分层bean、service和dao，为了减少它们的耦合并且由于持久层使用hibernate,所以考虑采用spring的ioc和它对hibernate的封装。所以将domain model放置于spring 容器中。考虑到表现层和域模型的分离，因此在表现层加上delegate一层，以封装各种服务端提供的服务（如webservice/ejb/其他一般的服务），来构架基于soa的系统。也由于表现层考虑采用jsf所以需要manage bean，但大侠所说的将manage bean 和域模型里的bean合并，那岂不将服务层和表现层（更确切地说应该是控制层），所以这里我还是有些不懂？

》将manage bean 和域模型里的bean合并
做个继承也可以，实则是同一个，这样简单，不要系统间DTO到处乱飞，增加复杂性。

一般情况下只有Service被Spring纳入容器管理，Domain Model不受这个拘束的，同一个Model可以出现在界面，也可以出现在持久层，但是在代码阶段他们是分离的，而在运行阶段则是混合的。

代码阶段和运行阶段意义不一样，我们强调分层，分离，更多是代码阶段。

收获不少。
但如果只有service纳入spring管理的话，那也只能用到spring的事物管理和aop，至于它ioc和对hibernate支持的话就用不上了？

在采用Spring框架的时候，想实现充血模型很难。我们只能通过IOC管理服务，而不能通过IOC管理domain model。并且java语言也不支持mixin特性，这样就使得实现充血模型更加困难。所以用DDD，我也推荐jdon框架和ROR.虽然目前正在研究jdon和ROR.

>IOC管理domain model
你已经认识到SSH框架之重，表示你有所觉悟，问题关键不是IOC是否可管理Domain Model，IOC代表水环境，Domain Model表示鱼，两者各负其责，在IOC中包含有数据库保存这样重量水环境，而Domain Model如果依赖数据库保存来实现业务逻辑，当让就会将Domain Model束缚于SSH等这样IOC框架，但是如果我们改变思路，不去依赖数据库操作实现业务，将DOmain Model作为真正的POJO，自由的，有自己的独立缓存生存空间，那么领域建模就能够施展。

而在SSH中，Domain Model的实体严重依赖Hibernate，表面上是POJO，实际不是真正POJO，也就是说不是真正能够脱离框架自由存在的对象，这个本质需要认识到，这也是我个人想法。当然，这种打着革命旗帜反革命事情经常有，取决于认识深度，不能指责个人。