系统架构的五个层次_通过“三层架构”理解前后端分工

九月底新书已经完稿了，本月开始回归日常分享，先分享一个简单的知识点开个场。 作为非技术出身的产品经理，很多同学在遇到一个功能出现问题时不知道应该找谁，时常因为找错人而尴尬，根本原因在于这些同学没有理解前后端是如何分工的。这篇文章我们就通过软件技术架构中的三层架构，来理解前后端的开发小哥们各自都是干啥的。 01 什么是三层架构 三层架构是软件技术架构中从技术实现角度对产品做的分层，有点类似于《用户体验要素》一书中对产品从五个层次做的划分，只是划分角度和目的不同。 如下图1所示，在三层架构中，将产品分为了表现层、业务层、数据层三个层次，下面我们就来看看这三个层次具体是什么含义。 图1  三层架构示意图 1、表现层 表现层(UIL：User Interface layer) ：通俗讲就是展现给用户的这套界面，即用户在使用产品时能够看到的、触摸到的这部分。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。如下图2所示的爱奇艺推荐页，我们所看到的这些内容全都属于表现层的范围。 图2  爱奇艺推荐页 2、业务层 业务层(BLL：Business Logic Layer) ：又称领域层，是进行业务逻辑处理的一层。根据表现层的具体指令、请求，按照已定义好的规则进行逻辑处理，并将处理好的数据返回给表现层。 业务层在三层架构中处于数据层与表现层的中间，在数据交换中起到了承上启下及处理的作用。

• 对于数据层，它是调用者；

• 对于表现层，它是被调用者。

整个后台的业务规则、业务流程等与业务需求有关的处理均在这一层次实现，所以直接决定数据层和表现层的设计。 3、数据层 数据层(DAL：Data access layer) 包括数据访问层和数据库两个部分：

• 数据访问层：主要是对数据库进行直接操作，包括对数据的增删查改等；

• 数据库：按照数据结构来组织、存储和管理数据的仓库。后端开发小哥们所说的数据字典就属于这一层的内容，而数据表的结构关系就是根据业务层的需求而定。

4、举例 仅仅通过概念去理解这三个层次比较困难，下面我们通过类比“餐厅点餐”来理解这三个层次的作用和关系。 顾客在餐厅点了一份红烧肉，服务员收到菜单后，将这个指令交给了厨师，厨师然后安排配菜师傅(据我曾在餐馆端盘子的经验：做菜的厨师一般会配有专门的配菜师帮助准备食材)从食材仓库取出猪肉等所需的食材，做些简单的处理、搭配后交给厨师，接着厨师再把红烧肉做好给到服务员上桌，顾客即可享用美食了。 在这个场景中，我们可以提炼出以下几个角色： 顾客、服务员、厨师、配菜师、食材仓库 它们分别对应三层架构中的 用户、表现层、业务层、数据层中的访问层、数据层中的数据库，对应关系 如下图所示。 图3  三层架构与餐厅各角色对应关系 用户要观看某个视频，就类似于顾客在餐厅要点了一份红烧肉，用户在列表中点击一个视频后，表现层(服务员)将“播放视频的指令”和“用户相关信息”(菜单)交给业务层(厨师)，业务层(厨师)根据指令和用户信息(菜单)，要求数据层中的访问层(配菜师)从数据库(食材仓库)中取出这个视频资源的地址、是否需要付费和此用户是否为会员等信息(食材)，然后业务层(厨师)根据已设置好的规则(如仅会员才可查看付费视频)返回给表现层(服务员)，表现层(服务员)再根据业务层(厨师)指示决定是否播放这个视频(是否给顾客上这道菜)。 整个过程中，表现层就像一个服务员，只是起到接受、传递用户要求和信息，并把业务层给的信息展示出来的作用；业务层则需要根据信息进行各种逻辑判断与处理，并指示数据访问层从数据库提取哪些数据；而数据层主要起到存储、返回数据的作用。 无论实际开发中是否按三层架构的模式来实现，我们在分析产品的技术分工时都可以按这三个层次来看。 02 前后端的分工 大多数情况下，这三个层次中由前端同学负责表现层，后端同学负责业务层和数据层，在一些分工比较细的公司，数据层可能会分给架构师负责，我们这里主要讨论前面一种更常见的情况。 所以，结合三层架构的概念，我们其实就能比较清楚的理解前后端分别负责什么了：

• 前端：负责与用户交互。主要工作是数据获取、页面布局展示、数据展示、完成各类动画动效、进行文字图片加载与渲染、视频播放和部分前端逻辑处理；
• 后端：负责进行业务逻辑处理和数据处理。主要工作是数据存储、数据处理、逻辑处理、数据输出。而这几个工作，是产品实现过程中任务最重，最复杂的地方，这也就是为什么我们在加新需求时，希望尽可能减少对后端影响的原因。我们一般遇到的流程没走通，数据、逻辑问题，大部分都与后端有关。

基于这些理解和认识，大多数情况下我们就能判断出各个功能的实现由谁负责、出了问题应该找谁了。不过，在具体实现过程中，还有一些前后端都可以做的灰色地带，需要具体情况具体分析，例如一个用户能否看到某个按钮的问题，通常有两种实现方式：

• 方式一：由前端实现角色的查看权限逻辑。用户登录后，后端将用户角色返回给前端，前端根据已经写好的逻辑，判断这个用户能否看到这个按钮；
• 方式二：由后端实现角色的查看权限逻辑。用户登录后，后端不需要返回用户角色，而是直接根据已经在业务层写好的角色查看权限逻辑，将这个用户能否看到这个按钮的结果告诉前端，前端根据结果直接做展示即可。

类似这样的灰色地带还有很多，具体由哪一端实现，与很多因素有关，不能一概而论，所以遇到这种情况，多问问前后端的实现逻辑就知道了。 另外，从这个例子也可以看出，前端不是完全不用做业务逻辑处理的，有些逻辑前端也可以做，而有的则必须由前端来处理，如后台数据返回不全、接口失效时，前端就需要做好应对措施，例如增加容错页面等。 好了，公众号的第一篇就写完了。一键三连的都是真爱，好人一生平安。