SSH的柜架中如何才能运用好设计模式呢！

所以，SSH并不是DDD框架，除了让你开始觉得好玩以外，并不能给你带来革命性思维改变。

单纯的SSH，也许并不复杂，整合好了换种思路去用就是了。

我是这么认为的。

不知道大家使用SSH的有没有这种感觉?

在您的团队是运用领域模型吗?

关键问题是，我们有些项目如果无法使用DDD的，比如原有系统的维护，就比较麻烦，我在这也发过贴报怨过，但总体就一条：走在正确的路上才能方便。

但再加一条：我们并不追求富血模型，我们只能是：如果能充血就充血吧，但有些时候的现实的阻力寸却没办法。

非常正确，我认为尤其是Hibernate限制了领域模型，Hibernate对于领域模型是很重的，这不能怪Hibernate，因为它只是一个ORM框架，不是一个真正领域模型持久化框架。

因为是ORM框架，所以Hibernate更多引入了数据库概念，但是又没有完全向OO程序员屏蔽这些关系数据库概念，所以，我们的领域模型结合Hibernate以后，反而被拖累了，在这方面，对象数据库是一个值得探索的方向。

从我个人来看：应该抛弃数据库这个Box盒子，这个单点，持久化框架应该是一个很轻量甚至程序员都没有觉察的框架，就象我在另外一个帖子说；它能够自动持久，无需我们来照顾。比如我们可以引入JMS专门做持久，这样可以彻底将持久和业务领域模型彻底分离，但是JMS又太重，也许并行计算中线程executor等是一个方向，但是线程接触太多又不好：

领域建模中的对象如何睡在数据库中:
http://www.jdon.com/jivejdon/thread/35047.html

Hibernate阻碍领域模型更重要的一点是：Hibernate没有完整提供领域模型的生命周期的Factory，Hibernate使用一级缓存Session来保存它创建的实体，但是这个缓存只是请求级别，不是application级别，领域模型应该是生存在application级别的内存中，那么我们就要配置Hibernate的二级缓存，但是Hibernate的二级缓存是为查询等优化的，而且是封闭的，不透明的，有时我们需要控制一些模型在保存二级缓存之前做一些特别业务处理，就很难做，还不如在Spring中间层自己做一个缓存，这就回到了JiveJdon的设计思路上来。

什么思路？就是要自己来处理对象的生命周期，来处理一些微妙的有关生命周期方面问题，因为缓存是对象的生存空间，如何保证缓存中某个对象实例的唯一性，是实现缓存的共享，还是实现prototype模式的对象复制，这些都需要依据值对象和实体特征确认和区别，如下：
http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=34936&message=23118451#23118451

这句话不太理解，保存到二级缓存之前要做一些什么样的操作呢？