目前公司的一个产品使用的架构是struts+sessionBean+DAO+DB模式，平时所谓的设计工作也都是在做数据库方面的设计，增加几个DAO方法，或是在原DAO方法上if else来满足客户需求，到目前为止系统已经有三年了，都没对整个系统做过重构，随着现在需求的增加，对一个小需求的修改往往迁一发动全身，谈不上遵循OO设计原则，根本看不到面象设计的优势，也就是使用面对象语言在做结构化编程吧。最终导致目前的一个现象是系统很复杂，一个需求要投入相当开发人员，测试也报怨影响范围大，测试时间不够。所以现在系统也应该是到了需要重新设计的时候了，各位给给意见。
这个现象很普遍，我在另外一个帖子刚刚说了：http://www.jdon.com/jivejdon/thread/40397#23132732
如果使用OO的封装方法，即使有BUG，那么也被封装边界局限在小范围内，不会无限制扩大，软件测试才有一条清晰的路径，很多人把测试工程师吹得神乎其神，我这里不是贬低测试工程师，而是测试工程师如果测试得不是一个边界划分得很好的软件时，简直生不如死。
面向对象讲究松耦合，细粒度，这些都是最大化划定边界，然后还有大小边界的组合。
现在的JavaEE主流架构无论是Spring_Hibernate,还是EJB+JPA/DAO，其实都是面向数据库编程，这是本来有自然边界的业务对象被压扁到成毫无意义的扁平数据，存在数据库，虽然有数据表表结构这个边界，但是粒度太粗，而且表结构不能随着我们对业务深入认识划分细化，进行频繁切割或合并。
所以，用普通的类直接表达业务对象，也就是领域建模，DDD现在已经相当成熟，在.NET世界也得到大家认可，使用这样MDD模型驱动开发方式能够帮我们现实世界中的业务对象的自然边界延伸到计算机内存中，出了问题，一一对应也好找，测试人员测试起来方便轻松。
所以，如果一个软件测试很费时费力，不是测试工程师水平低，而是你的软件系统需要重构。
希望以上对你有所帮助。
重构规模分两种：
一个是重构业务模型，把数据表模型转换成领域模型，可能要再次分析需求，重新整理画出类图，因为是从头来过，相当于重写。
第二个，是避开业务模型，避开数据表数据，只重构操作类，比如重构session bean或Spring的服务，将其粒度分细，分解它们，因为不涉及业务模型，所以，粒度细到一定程度就没有办法了。
在第二种基础上也有性能可伸缩性重构，就是shade碎片割分数据库，比如用户放一个数据库，产品放另外一个数据库，这样分解，有时会涉及到session bean或Spring的服务的分解。
总之，业务数据是一个软件系统的根，session bean或Spring的bean(XML中配置)是软件系统的叶，这颗树病了，根据你的能力从哪里下手。
结构化程序设计是刀,面向对程序设计是剑,无论使用哪种武器,只有功力高的人才能允分发挥它们的力量,高手们能把最原始的武器赋予它无限的力量.我想说的是不要为了追求技术而使用技术,提高自身的水平,最简单的技术也能实现复杂的功能.
唉，重构有点不现实吧，这样的项目应该说是重做，从技术架构层面就开始改动。不过这样的话，成本实在是太高了，除非用户愿意花钱让你们来做这项事情，否则领导肯定不同意的。如果用spring的话，可能会好点，重构这样的项目需要对业务和技术细节都非常了解，否则没有人敢下手大刀阔斧的重构，这个是很需要信心、细心和魄力的，如果这个系统是在金融等敏感领域，建议不要重构，否则你付不起这个责任，最好是重做，从技术架构到业务梳理，要有完整的项目计划，有充分的测试时间，还有对线上发布的影响评估等。不能单纯从技术角度思考问题。