软件架构分层，你的项目处于什么阶段？

前言

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

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

不采用架构分层，行不行h2>

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

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

什么是架构分层h2>

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

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

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

• 高内聚：分层设计可以简化系统设计，让不同层专注做某一模块的事；
• 低耦合：层与层之间通过接口或API来交互，依赖方不用知道被依赖方的细节；
• 复用：分层之后可以做到代码或功能的复用；
• 扩展性：分层架构可以让代码更容易横向扩展

通讯领域的OSI参考模型

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

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

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

经典三层架构

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

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

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

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

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

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

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

• 对第三方平台封装的层，预处理返回结果及转化异常信息。
• 对Service层通用能力的下沉，如缓存方案、中间件通用处理。
• 与DAO层交互，对多个DAO的组合复用。

其各层的作用如下：

• 终端显示层：各端模板渲染并执行显示的层。当前主要是Velocity渲染，JS渲染， JSP渲染，移动端展示等。
• 开放接口层：将Service层方法封装成开放接口，同时进行 关安全控制和流量控制等。
• Web层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
• Service层：业务逻辑层。
• Manager层：通用业务处理层。
• DAO层：数据访问层，与底层 MySQL、Oracle、HBase 等进行数据交互。
• 外部接口或第三方平台：包括其它部门RPC开放接口，基础平台，其它公司的HTTP接口。

系统工程结构

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

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

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

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

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

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

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

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