如何对现在系统架构进行改造

这个现象很普遍，我在另外一个帖子刚刚说了：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中配置)是软件系统的叶，这颗树病了，根据你的能力从哪里下手。