只要从事软件开发的工作，系统架构是必备知识。有朋友说可能会说，我只是一个搬砖的，怎么会接触到架构知识呢？其实，除了架构的设计者（也就是架构师），作为普通的开发者也是在时刻践行着系统架构的理论。毕竟，再好的架构，都需要码农去实施。只不过当你没有系统了解软件架构时，可能感知不到而已。

本篇文章就带大家系统的了解一下软件架构的分层，学习完毕，你就会明白，为什么系统要分层。同时，也能准确地看清楚目前自己系统中采用的是什么样的分层架构。

不采用架构分层，行不行？

首先我们来思考一个问题，如果一个系统不采用分层架构可不可以？这个问题就好像在问，代码中不使用设计模式行不行？答案当然是可以的。但不采用架构分层，会带来极大的未知风险，或者说代码极具熵增的特性。

作为一个初创软件，可能没有什么业务逻辑，没有什么用户量，而软件最主要的目标就是快速上线，实践商业模式。此时，可以不考虑分层。但随着业务逻辑的复杂，业务板块的增多，彼此之间就会出现错综复杂的依赖关系，随之就会产生的逻辑不清晰、可读性差，维护困难，改动一处动全身等问题。

什么是架构分层？

分层架构是将软件模块按照水平切分的方式分成多个层，一个系统由多层组成，每层由多个模块组成。同时，每层有自己独立的职责，多个层次协同提供完整的功能。比如，我们经常提到的 MVC 架构，就是一种非常典型非常基础的分层方式。

分层设计的本质其实就是将复杂问题简单化，基于单一职责原则让每层代码各司其职，基于“高内聚，低耦合”的设计思想实现相关层对象之间的交互。从而，提升代码的可维护性和可扩展性。

系统架构分层之后，往往需要达到以下目标：

• 高内聚：分层设计可以简化系统设计，让不同层专注做某一模块的事；

• 低耦合：层与层之间通过接口或 API 来交互，依赖方不用知道被依赖方的细节；

• 复用：分层之后可以做到代码或功能的复用；

• 扩展性：分层架构可以让代码更容易横向扩展

通讯领域的 OSI 参考模型

在计算机领域现有最典型的分层架构设计就是 OSI 参考模型和 TCP/IP 参考模型了。关于这个模型，我们在《 一篇文章，只用看三遍，终生不忘网络分层! 》一文中已经详细介绍了。下面直接看一下相关的模型图：

对于上述的三种分层模式，试想一下，如果没有分层，当一个业务或协议需要改变时，我们只能针对整个系统做修改或扩展。而分层之后，便可以很方便地把不同功能的模块抽离出来，修改对应的模块即可。而且不同层还可以被复用，只要确保按照这个层的协议来处理就可以了。

软件系统整体分层

以 Java 软件应用为例，整个软件系统也可进行分层，比如分为部署的硬件环境、操作系统、所需的中间件、承载业务的应用程序以及软件接入层。可通过下图进行整体了解：

对于上述分层也产生了对应在职位，比如运维工程师、中间件工程师、产品经理、开发工程师、测试工程师等工种。而我们在实践过程中，接触最多，使用最多的分层要属应用软件层了，其次是中间件层。

下面我们就来看看针对应用软件层通常有哪些分层方式。

经典三层架构

三层架构(3-tier application) ，通常就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。

表现层（UI），通俗讲就是展现给用户的界面，对应项目中的 Web 层包含 Servlet 和 Controller 等。

业务逻辑层（BLL）：也称作领域层，负责系统业务逻辑的处理，对应项目中 Service 和 ServiceImpl 等。

数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等，对应项目中的 Dao。

在提出该分层架构的时代，多数系统往往较为简单，本质上都是一个单体架构（Monolithic Architecture）的数据库管理系统。这种分层架构已经是 Client-Server 架构的进化了，它有效地隔离了业务逻辑与数据访问逻辑，使得这两个不同关注点能够相对自由和独立地演化。

在开源技术框架中，表现层实现的代表作品是 Struts1/2、Spring MVC，业务层实现的代表作品是 Spring，持久层实现的代表作品是 Hibernate 和 Mybatis。

MVC

MVC 全名是 Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC 被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

标准的 MVC 交互模型如下图：

View：视图，为用户提供使用界面，与用户直接进行交互。

Model：模型，承载数据，对用户提交请求进行计算的模块。分为两类，一类称为数据承载 Bean，一类称为业务处理 Bean。数据承载 Bean 是指实体类，专门承载业务数据的，如 Student、User 等。而业务处理 Bean 则是指 Service 或 Dao 对象，专门用于处理用户提交请求的。

Controller：控制器，用于将用户请求转发给相应的 Model 进行处理，并处理 Model 的计算结果向用户提供响应。

从图中可以看到，标准的 MVC 中模型能主动推数据给视图进行更新（观察者设计模式，在模型上注册视图，当模型更新时自动更新视图），但在 Web 开发中模型是无法主动推给视图（无法主动更新用户界面），因为在 Web 开发是请求-响应模型。

Web MVC 标准架构，如下图所示：

在 Web MVC 模式下，模型无法主动推数据给视图，如果用户想要视图更新，需要再发送一次请求（即请求-响应模型）。MVC 用于将 web（UI）层进行职责解耦。

三层架构和 MVC 的区别与联系

MVC 严格说是三层架构中的 UI 层，也就是说，MVC 把三层架构中的 UI 层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话，而 C 层直接与三层中的 BLL 进行对话。

三层架构和 MVC 可以共存。三层架构是基于业务逻辑来分的，而 MVC 是基于页面来分的。MVC 是表现模式（Presentation Pattern），三层架构是典型的架构模式（Architecture Pattern）。

三层架构的分层模式是典型的上下关系，上层依赖于下层。但 MVC 作为表现模式是不存在上下关系的，而是相互协作关系。即使将 MVC 当作架构模式，也不是分层模式。MVC 和三层架构基本没有可比性，是应用于不同领域的技术。

阿里四层架构

三层架构实现比较简单，很多朋友可能觉得项目分层就应该如此，结果就是往往会出现一大堆的业务逻辑都堆砌在 Service 层中。而在《阿里巴巴 Java 开发手册 》中将原来的三层架构进一步细化，添加了 Manager 通用业务处理层。

Manager 层可以将原 Service 层的一些通用能力进行下沉，比如与缓存和存储交互策略，中间件的接入；还可以封装对第三方接口的调用，比如调用支付服务，调用审核服务等 RPC 接口。

通用业务处理层，它有如下特征：

• 对第三方平台封装的层，预处理返回结果及转化异常信息。

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

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

其各层的作用如下：

• 终端显示层：各端模板渲染并执行显示的层。当前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移动端展示等。

• 开放接口层：将 Service 层方法封装成开放接口，同时进行网关安全控制和流量控制等。

• Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。

• Service 层：业务逻辑层。

• Manager 层：通用业务处理层。

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

• 外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。

系统工程结构

在学习了以上分层架构之后，下面来看一下针对分层在软件系统中的对照关系表：

以上分层定义仅供参考。在上表中还多出了对外接口层和接入层。

对外接口层：所有对外的接口放在这层，不能包含任何业务逻辑，只数据对象的转换和异常的封装。

接入层：所有外部系统的依赖放在这层，好处是一旦外部系统接口修改，只需要在一处修改即可。

DDD 分层架构

DDD 是一种处理高度复杂领域的设计思想，试图分离技术实现的复杂性，同时围绕业务概念构建领域模型，提出的一种软件架构设计的方法论。

DDD 分层架构将数据、缓存等都视为基础层， 可以被所有层调用；抽离了领域层，负责核心业务逻辑处理，领域层调用外部依赖全部通过接口，以保证领域层的 100%单测覆盖率；应用层聚合多个领域层的能力，只做功能的组合、转发，不负责具体业务逻辑。

我们这里只做 DDD 分层架构的简单介绍，关于 DDD 概念不做过多拓展，相关架构模式可专门进行学习一下。看一下 DDD 分层的架构图：

其中对应层的功能介绍如下：

接口层（Interfaces）：该层包含与其他系统交互的所有内容，如 Web 服务器、RESTful 接口。接口层处理传入数据的解释、校验、编解码、序列化操作，同时可以考虑引入专门的 DTO（数据转换对象）来协助数据转换；

应用层（Application）：该层负责驱动应用程序完成工作流程。很薄一层，协调多个领域对象(实体、聚合根、领域服务)实现服务编排和组合完成工作流，该层通常不应该包含具体业务逻辑。该层涉及：其他微服务 RPC 调用、微服务编排和组合、分布式事务实现、消息驱动事件的驱动、日志记录等。

领域层（Domain）：该层是软件的核心，包含业务逻辑具体实现，包含实体、值对象、聚合、领域服务、仓储接口等领域对象内容，通常该层应该配备图示告知软件是如何工作的；

基础层（Infrastructure）：包含网关、缓存、数据库存储、消息中间件、监控、应用程序服务等通用的技术和基础服务。基础层以不同方式支持到其他三层，促进各层间通信。配置文件、数据库 Schema 模式定义以及仓储接口实现都是基础结构的一部分；

DDD 分层架构传统三层架构的比较

DDD 四层架构也基于传统三层架构的，看一下它们之间的对照关系：

DDD 四层架构和传统三层架构有以下区别：

• 关注点不一样：三层架构关注请求调用顺序；DDD 架构关注领域服务。

• 横向划分方式不一样：三层架构主要关注纵向划分，对横向划分没有约定；DDD 架构更关注纵向，即：多个领域层之间划分及交互方式。

• 对资源的定位不一样：三层架构把所有依赖的数据都放到数据访问层；DDD 架构只将领域相关联的数据放到 Repository 中，其他比如 API 层缓存、文件等都当成基础服务来处理。

关于 DDD 架构分层还有整洁架构和六边形架构两种形式，这里就不再拓展，感兴趣的朋友可自行查找相关资料进行学习。

小结

本篇文章为大家讲解了市面上常见的架构分层。分层架构的目的是通过关注点分离来降低系统的复杂度，同时满足单一职责、高内聚、低耦合、提高可复用性和降低维护成本。但分层架构同样也有一定的缺点，比如开发成本高、性能略低、可扩展性低等问题。实践中，可根据需要选择合适的分层架构。