前言
最近review公司的代码,发现现在整个代码层级十分混乱,一个service类的长度甚至达到了5000多行。而且各种分层模型DTO、VO乱用, 最终出现逻辑不清晰、各模块相互依赖、代码扩展性差、改动一处就牵一发而动全身等问题。
我们在吸取了阿里巴巴的分层规范以及网上的一些经验后,重新梳理总结了属于我们项目的分层规范。
三层架构VS四层架构
我们公司原来的分层采用的是传统的三层架构,比如在构建项目的时候,我们通常会建立三个目录:Web、Service 和 Dao,它们分别对应了表现层、逻辑层还有数据访问层。
这样导致一个很大的问题,随着业务越来越复杂,逻辑层也就是service层越来越庞大,所以出现了前面说的5000多行的类,可想而知维护成本有多大。
参照阿里发布的《阿里巴巴 Java 开发手册 v1.4.0(详尽版)》,我们可以将原先的三层架构细化成下面的样子:
- 终端显示层:各端模板渲染并执行显示的层。当前主要是 Velocity 渲染,JS 渲染, JSP 渲染,移动端展示等。
- 开放接口层:将
Service
层方法封装成开放接口,同时进行网关安全控制和流量控制等。 Web