后端应用分层经验总结

　　后端应用分层是什么，例如：你用Spring MVC开发web程序、项目用三层架构分包，这些都用了分层思想。

　　MVC模式包含了三部分：

• 视图(view)：负责界面显示、处理用户交互。如：前端应用

• 控制器(controller)：协调视图层与模型层之间的相互工作。控制器接收视图层发来的请求，决定用那些模型来处理，以及处理完后用那些视图显示结果。

• 模型(model)：模型持有所有数据、状态和程序逻辑。接收控制器转发来的视图请求，处理请求并返回结果。

    　实际开发中，视图层可以用JSP/HTML/CSS、或者用Vue/React实现，控制器层用Servlet来接收并响应请求，模型层用JavaBean实现。以上功能SpringMVC框架都集成了，使用它能够轻松地开发出MVC应用。

　　MVC模式中的model层承担了太多工作，不符合单一职责原则，随着系统复杂度越来越高，程序变得越难维护。因此再次使用分层的思想把model层拆分为业务逻辑层（负责程序逻辑）、数据访问层（负责与数据库交互）。model层只剩下薄薄的一层，负责中转数据。再把视图view、控制器controller这两部分合并为展示层，应用就演变成了传统的三层架构。如下图：

　　应用通过分层使得程序结构清晰、耦合低，升级和维护都变得十分容易。开发人员只需关注一层，不必担心自己的设计会影响到其他层，对提高软件质量大有好处。如果要更改某一层的具体实现代码，只要本层的接口保持稳定，对其上层可以不用修改。可以很容易地用新的实现来替换原有层的实现。即使本层的接口发生变化，也只影响到相邻的上层，修改工作量小且错误可以控制，不会带来意外的风险。

       分层架构的一个重要原则是每层只能与位于其下方的层发生耦合。分层架构分为两种，严格分层架构和松散分层架构。在严格分层架构中，某层只能与位于其直接下方的层发生耦合；在松散分层架构中，则允许某层与它的任意下方层发生耦合。三层架构就是严格分层架构，其缺点是可能会导致每层级联的修改。这种修改尤其体现在自上而下的方向，比如，展示层要增加一个数据显示，业务逻辑层要计算好数据并返回，数据访问层可能要从其他数据源中读取到数据。

       领域驱动设计是采用松散分层架构，整个系统划分为基础设施层、领域层、应用层和展示层。领域层是系统的核心，是抽象且稳定的一层，它包含业务流程、业务规则、功能接口。在领域层定义的接口是交由基础设施层去实现，这样只要高层接口稳定，底层实现可以被替换。这个叫依赖倒置原则，高层不与底层紧耦合，不依赖于具体实现，用来改善每层引起的级联修改。

　　下面介绍下阿里巴巴推荐的分层结构，相比于三层架构，增加了开发API层、通用逻辑层(Manager层)。如下图：

• 开发API层：是定义了一层对外提供的接口，不依赖其他层，是提供给其他系统调用的SDK开发包。由Service层依赖并实现业务逻辑，对外访问会暴露成RPC接口或者Http接口，内部调用则引用具体的实现。

• 终端显示层：各个端的模板渲染并执行显示的层。主要是velocity 渲染，JS 渲染，JSP 渲染，移动端展示等。现在流行的前后端分离的开发模式，而前端开发框架React/Vue已承担了页面渲染、路由、状态管理等工作，所以这一层根据自己需求来添加。

• Web 层：提供给客户端访问的接口，主要是对访问控制进行转发，各类基本参数校验。

• Service 层：相对具体的业务逻辑服务层。

• Manager 层：通用业务处理层。位于Service层与Dao层中间，主要作用如下：

• 1）对第三方平台封装，预处理返回结果及转化异常信息，适配上层接口，相当于DDD中的防腐层。

• 2）对 Service 层通用能力的下沉，如缓存方案、中间件通用处理。

• 3）与 DAO 层交互，对多个 DAO 的组合复用。

• DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase、OB 等进行数据交互。

• 第三方服务：包括其它部门 RPC 服务接口，基础平台，其它公司的 HTTP 接口。这一层没必要单独一层，可以移到Manager层来做第三方服务封装。

• 外部数据接口：给外部(应用)数据存储服务提供的接口，多用于数据要做二次加工与迁移的场景中。