为什么系统要分层如何知晓公司系统中采用的是什么分层架构 _为什么软件要分系统

只要从事软件开发的工作，系统架构是必备知识。有朋友说可能会说，我只是一个搬砖的，怎么会接触到架构知识呢？其实，除了架构的设计者（也就是架构师），作为普通的开发者也是在时刻践行着系统架构的理论。毕竟，再好的架构，都需要码农去实施。只不过当你没有系统了解软件架构时，可能感知不到而已。
本篇文章就带大家系统的了解一下软件架构的分层，学习完毕，你就会明白，为什么系统要分层。同时，也能准确地看清楚目前自己系统中采用的是什么样的分层架构。
不采用架构分层，行不行？首先我们来思考一个问题，如果一个系统不采用分层架构可不可以？这个问题就好像在问，代码中不使用设计模式行不行？答案当然是可以的。但不采用架构分层，会带来极大的未知风险，或者说代码极具熵增的特性。
作为一个初创软件，可能没有什么业务逻辑，没有什么用户量，而软件最主要的目标就是快速上线，实践商业模式。此时，可以不考虑分层。但随着业务逻辑的复杂，业务板块的增多，彼此之间就会出现错综复杂的依赖关系，随之就会产生的逻辑不清晰、可读性差，维护困难，改动一处动全身等问题。
什么是架构分层？分层架构是将软件模块按照水平切分的方式分成多个层，一个系统由多层组成，每层由多个模块组成。同时，每层有自己独立的职责，多个层次协同提供完整的功能。比如，我们经常提到的MVC架构，就是一种非常典型非常基础的分层方式。
分层设计的本质其实就是将复杂问题简单化，基于单一职责原则让每层代码各司其职，基于“高内聚，低耦合”的设计思想实现相关层对象之间的交互。从而，提升代码的可维护性和可扩展性。
系统架构分层之后，往往需要达到以下目标：
高内聚：分层设计可以简化系统设计，让不同层专注做某一模块的事；低耦合：层与层之间通过接口或API来交互，依赖方不用知道被依赖方的细节；复用：分层之后可以做到代码或功能的复用；扩展性：分层架构可以让代码更容易横向扩展通讯领域的OSI参考模型在计算机领域现有最典型的分层架构设计就是OSI参考模型和TCP/IP参考模型了。关于这个模型，我们在《一篇文章，只用看三遍，终生不忘网络分层! 》一文中已经详细介绍了。下面直接看一下相关的模型图：

文章插图
对于上述的三种分层模式，试想一下，如果没有分层，当一个业务或协议需要改变时，我们只能针对整个系统做修改或扩展。而分层之后，便可以很方便地把不同功能的模块抽离出来，修改对应的模块即可。而且不同层还可以被复用，只要确保按照这个层的协议来处理就可以了。
软件系统整体分层以Java软件应用为例，整个软件系统也可进行分层，比如分为部署的硬件环境、操作系统、所需的中间件、承载业务的应用程序以及软件接入层。可通过下图进行整体了解：

文章插图
对于上述分层也产生了对应在职位，比如运维工程师、中间件工程师、产品经理、开发工程师、测试工程师等工种。而我们在实践过程中，接触最多，使用最多的分层要属应用软件层了，其次是中间件层。
下面我们就来看看针对应用软件层通常有哪些分层方式。
经典三层架构三层架构(3-tier application) ，通常就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。