你的【架构设计】应用该如何分层呢？

前言

最近review公司的代码，发现现在整个代码层级十分混乱，一个service类的长度甚至达到了5000多行。而且各种分层模型DTO、VO乱用， 最终出现逻辑不清晰、各模块相互依赖、代码扩展性差、改动一处就牵一发而动全身等问题。

我们在吸取了阿里巴巴的分层规范以及网上的一些经验后，重新梳理总结了属于我们项目的分层规范。

三层架构VS四层架构

我们公司原来的分层采用的是传统的三层架构，比如在构建项目的时候，我们通常会建立三个目录：Web、Service 和 Dao，它们分别对应了表现层、逻辑层还有数据访问层。

这样导致一个很大的问题，随着业务越来越复杂，逻辑层也就是service层越来越庞大，所以出现了前面说的5000多行的类，可想而知维护成本有多大。

参照阿里发布的《阿里巴巴 Java 开发手册 v1.4.0（详尽版）》，我们可以将原先的三层架构细化成下面的样子：

• 终端显示层：各端模板渲染并执行显示的层。当前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移动端展示等。
• 开放接口层：将 Service 层方法封装成开放接口，同时进行网关安全控制和流量控制等。
• Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
• Service 层：业务逻辑层。
• Manager 层：通用业务处理层。主要实现下面的功能，1） 对第三方平台封装