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

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

showerxp
2011-04-05 09:26
2011年03月31日 10:04 "
jsonman"的内容
增加几个DAO方法,或是在原DAO方法上if else来满足客户需求 ...

如果是DAO,那么就应当换起本来面目——数据访问接口对象,只单纯关注数据库的CRUD,也就是说不能掺杂任何业务逻辑,也不需要做复杂的变动,更不能在DAO方法上添加if else。
看楼主的状况,可能是不能满足业务需求了,那么就可以勇敢的废弃掉原来的系统,就像好公司采用激进策略时候,敢于将固定资产折旧。
需求因人因时不断变化,如何适应这些变化,如何使得这个适应变化的过程是收敛的、迭代的(系统在原来基础上“进化”以适应需求变化,而不是一有变动系统就要推倒重来)?这就考验编程者的智慧。OO抽象化的编程思想也由此应运而生。

2011年04月02日 11:08 "
hongs2001"的内容
结构化程序设计是刀,面向对程序设计是剑, ...

hongs2001说的刀剑理论看似中庸和谐,实则我不敢苟同。我认为面向对象与结构化像是鸡头凤尾的关系,宁做陌生领域的“鸡头”,而不做熟悉领域的“凤尾”。这是由发展趋势决定的。

[该贴被showerxp于2011-04-05 09:27修改过]

[该贴被showerxp于2011-04-05 09:28修改过]

spell
2011-04-13 11:21
唉,重构有点不现实吧,这样的项目应该说是重做,从技术架构层面就开始改动。不过这样的话,成本实在是太高了,除非用户愿意花钱让你们来做这项事情,否则领导肯定不同意的。如果用spring的话,可能会好点,重构这样的项目需要对业务和技术细节都非常了解,否则没有人敢下手大刀阔斧的重构,这个是很需要信心、细心和魄力的,如果这个系统是在金融等敏感领域,建议不要重构,否则你付不起这个责任,最好是重做,从技术架构到业务梳理,要有完整的项目计划,有充分的测试时间,还有对线上发布的影响评估等。不能单纯从技术角度思考问题。

猜你喜欢