重新设计已有系统的架构,看下可否行得通
项目目前描述:
1.项目基本没做什么架构设计
2.为了达到快速开发,达到定期交付的目的,项目采用目前最最流行的s2sh框架,基本分层为:表现层+业务层(业务都写在service),连DAO层都省了,用HIBERNATE里的模板包装成一个通用的dao搞定。
3.直接用持久化对象作为传输对象在表现层与业务层之间传递
4.模块没有划分,很多耦合在一起,重复代码一大堆
5.项目是已经交付了,现在是维护期,有用户提的新需求及BUG,现在已经感觉越来越难维护了,而且项目还会有二期、三期,并且接下来会有各种与其他系统的整合需求提出。
针对目前的情况,我已经跟项目经理提出过这种情况(项目经理也没什么经验,纯理论型的),要我这边整理一个架构文档,并且估计工作量,我是其中的一个开发人员,也没架构经验,没办法,没架构师,这事也只能落到我这边了,也请大家多多帮忙呀!依我之见,主要有以下几点需要调整:
1:引入DTO,持久层对象与DTO司其职,这样也可以达到解藕,DTO与持久对象还是有一些区别的。
2:原来service只是作为提供业务的服务对象,而不是在里面实现业务的地方。
3:把实现业务的地方单独出来一个领域层,注意:我这里说的这个层与实际的领域层是有区别的,这里的领域对象更多的是只有行为,没有属性,很多单元操作的业务会放到这里。因为这里持久层对象还是保持不变,也就是保持贫血状态。主要是出于工作量的考虑及开发人员对领域建模的水平考虑。
4:建立DAO层,把持久化任务从业务层解放出来。
5:划分粗模块,目前不考虑划分得很细,目前是的项目代码全是放一起的,打算划分成比较粗的几个工程,以jar包集成,我比较重视的是公共的模块,这个模块是每个地方都要用到的,比如用户管理等
6:迭代的重构方法,第一次迭代会先对公共模块下手(因为是公共的,所以很多地方有重复代码)。
7:用声明模式(在J道上看到的)解决到处拼SQL的问题
8:用AOP或过滤器链的方式解决数据权限的问题
暂时想到这些,不知是否可行?大家多多给锤锤