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

11-03-31 jsonman
                   

目前公司的一个产品使用的架构是struts+sessionBean+DAO+DB模式,平时所谓的设计工作也都是在做数据库方面的设计,增加几个DAO方法,或是在原DAO方法上if else来满足客户需求,到目前为止系统已经有三年了,都没对整个系统做过重构,随着现在需求的增加,对一个小需求的修改往往迁一发动全身,谈不上遵循OO设计原则,根本看不到面象设计的优势,也就是使用面对象语言在做结构化编程吧。最终导致目前的一个现象是系统很复杂,一个需求要投入相当开发人员,测试也报怨影响范围大,测试时间不够。所以现在系统也应该是到了需要重新设计的时候了,各位给给意见。

                   

8
banq
2011-03-31 14:41

2011年03月31日 10:04 "

jsonman"的内容

测试也报怨影响范围大,测试时间不够 ...

这个现象很普遍,我在另外一个帖子刚刚说了:http://www.jdon.com/jivejdon/thread/40397#23132732

如果使用OO的封装方法,即使有BUG,那么也被封装边界局限在小范围内,不会无限制扩大,软件测试才有一条清晰的路径,很多人把测试工程师吹得神乎其神,我这里不是贬低测试工程师,而是测试工程师如果测试得不是一个边界划分得很好的软件时,简直生不如死。

面向对象讲究松耦合,细粒度,这些都是最大化划定边界,然后还有大小边界的组合。

现在的JavaEE主流架构无论是Spring_Hibernate,还是EJB+JPA/DAO,其实都是面向数据库编程,这是本来有自然边界的业务对象被压扁到成毫无意义的扁平数据,存在数据库,虽然有数据表表结构这个边界,但是粒度太粗,而且表结构不能随着我们对业务深入认识划分细化,进行频繁切割或合并。

所以,用普通的类直接表达业务对象,也就是领域建模,DDD现在已经相当成熟,在.NET世界也得到大家认可,使用这样MDD模型驱动开发方式能够帮我们现实世界中的业务对象的自然边界延伸到计算机内存中,出了问题,一一对应也好找,测试人员测试起来方便轻松。

所以,如果一个软件测试很费时费力,不是测试工程师水平低,而是你的软件系统需要重构。

希望以上对你有所帮助。

jsonman
2011-04-01 11:15

2011年03月31日 14:41 "

banq"的内容

用普通的类直接表达业务对象,也就是领域建模 ...

感谢banq的回复,领域建模是否就是将数据表表对象抽象成类对象,能否指导下如何做好领域建模。

banq
2011-04-01 13:58

重构规模分两种:

一个是重构业务模型,把数据表模型转换成领域模型,可能要再次分析需求,重新整理画出类图,因为是从头来过,相当于重写。

第二个,是避开业务模型,避开数据表数据,只重构操作类,比如重构session bean或Spring的服务,将其粒度分细,分解它们,因为不涉及业务模型,所以,粒度细到一定程度就没有办法了。

在第二种基础上也有性能可伸缩性重构,就是shade碎片割分数据库,比如用户放一个数据库,产品放另外一个数据库,这样分解,有时会涉及到session bean或Spring的服务的分解。

总之,业务数据是一个软件系统的根,session bean或Spring的bean(XML中配置)是软件系统的叶,这颗树病了,根据你的能力从哪里下手。

hongs2001
2011-04-02 11:08

结构化程序设计是刀,面向对程序设计是剑,无论使用哪种武器,只有功力高的人才能允分发挥它们的力量,高手们能把最原始的武器赋予它无限的力量.我想说的是不要为了追求技术而使用技术,提高自身的水平,最简单的技术也能实现复杂的功能.

2Go 1 2 下一页