因为Spring的Example离我们的实际应用都很远，Example里的Model层便不具有代表性，因此就埋下了祸根， Domain-Driven逢初一、十五都会被拿出来讨论一遍。
其实我觉得，无论什么模式，都不过是一种人为的划分，抽象和封装。只要在团队里理解一致，感觉良好就行了。在我的Model层里，只有VO和Manager两位，VO作为纯数据载体，而Manager类放置商业方法，用getHibernateTemplate()直接访问数据库，在一些主要的Manager类里会包含一些小的同类。
1.VO:考虑到VO如果带商业方法的话，因为它代表的是单个个体，无法承载针对个体集合的方法比如findOrderList()方法，这些方法始终还是要放在Manager类来做，另外基于传到View层的代价，代码自动重新生成的代价，不如把商业方法统一放在Manager类里。
2.Manager: 1.不使用纯DAO。以往的DAO是为了透明不同数据库间的差异，而现在Hibernate已经做的很好了。目前DAO的更大作用，是为了将来可以切换到别的ORM方案比如iBatis，但一个Pragmaic的程序员显然不会无聊到为了这个理由去做一个纯DAO层，直接使用getHibernateTemplate()已经足够。
2.也不使用纯的薄Service层。在JetpetStore里有一个很薄的Service层，Fascade了一堆DAO类，把这些DAO类的所有方法都僵硬的重复了一遍。而我认为Fascade的意义在二：
一是Controller调用Manager甲的时候，总会伴随着调用Manager乙的某些方法。使用Fascade可以避免Controller零散的调用一堆Manager类。
二是一个商业过程里可能需要同时调用甲乙丙丁的方法。
因此，我会在一些主要的Manager类里灵活的使用Fascade，在需要调用其他Manager的方法时就包含它，或者在其他Manager的某些方法总是被伴随调用时，就有选择的代理它的这个方法。
始终都没有在Manager类之上再建单独的一层Service类，我讨厌类膨胀，另外Fascade只是选择性的，Controler如果要同时面对Manager类和Service类有点脚深脚浅，那还不如都在Manager层里完成。
因此，我的模式里，VO作为纯数据载体，Manager类放商业方法。有人说这样太简单了，但一个应用，要划成一个JSP，一个Controller，一个Manager，一个VO，对我来说已经足够复杂，再要往上架墙叠屋，恕不奉陪，起码在我的应用范围里不需要。