软件开发分层的意义(谈谈软件分层架构模式--为什么要分层、优缺点、分层方式)

　　概述

　　这么多年大大小小也做了很多软件项目，今天主要闲聊下软件的分层架构模式。

　　为什么要分层？

　　犹记得高中数学老师说碰到难题的时候一定要分解，把复杂的问题拆成一步一步来做，做着做着就会发现很难的问题就解决了，即使解决不了，按步也是可以给到很多分的...其实就是把一个复杂的问题分解成为若干个简单的问题来进行处理，这样要比解决一个复杂的问题简单。

　　同理，在设计一个复杂的软件系统的时候，我们也通常使用的一个技术就是分层，每个层只负责完成自身的功能，所有的层整合起来构成一个复杂的软件系统。

　　在应用软件开发中，N层应用软件模型是一种典型的软件系统架构，也就是所谓的分层架构。N层的应用软件系统，由于其众多的优点，已经成为典型的软件系统架构，也已经成为构建企业软件的标准。 其中最典型的也就是三层架构。

　　分层也是计算机技术中的常用方法，一个典型的例子就是TCP/IP技术的OSI七层模型。

　　软件分层架构优缺点

　　分层的程序设计带来的好处如下：

　　1.高内聚低耦合，便于团队开发

　　内聚：一个模块内各个元素彼此结合的紧密程度；

　　耦合：一个软件结构内不同模块之间关联程度的度量。

　　在团队开发中，分层可以让软件开发人员专注于自己负责的层，而不必关心其他层的设计，也不必担心自己的设计会影响其它层。如果不分层，根本不可能进行团队开发，只会一团糟。

　　2.使软件升级和维护更为容易

　　分层设计使得程序结构清晰，升级和维护都变得十分容易，更改层的具体实现代码，只要层接口保持稳定，其他层可以不必修改。即使层的接口发生变化，也只影响上层和下层，修改工作量小而且错误可以控制，不会带来意外的风险。

　　分层式结构也不可避免具有一些缺陷：

　　1.降低系统性能

　　如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

　　2.有时会导致级联的修改

　　有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

　　3.代码量变多

　　分层后代码量自然要比不分层多。

　　项目分层方式

　　1. 按类别（适合小型项目）

　　在 Android 开发早期，很多项目都是按照类别分层的，就是按照 activity、fragment、adapter 等来进行分层，按照类别进行分层的项目的目录结构大概是下面这种：

　　相信大家对这种结构非常熟悉，这种分层方式的好处是：

　　简单明了，很容易知道每个子包下存放的是什么。一旦项目采用这种分层方式，将来项目无论怎么迭代和变化，目录结构都不需要做太大的改动。

　　但这种方式缺点也是很明显的，如果项目太大，有上百个界面，那么在 activity 子包下会有上百个类，那样要定位到具体某个功能模块的 activity 会变得很困难，也就是说这种方式不够精细，随着项目迭代功能越来越多，会导致代码导航越来越困难。

　　2. 按功能（适合中大型项目）

　　这种分包方式是按照模块划分的，同一功能模块相关的类都在一个文件夹下，项目的目录结构大概如下：

　　以上的分层可以看到有一个叫feature的包，这里面包含了 app 的一些功能，如 freshnews、login分别代表 app 内部的新鲜事、登录等一些功能模块，这种按功能模块的分层好处很明显：

　　很直观，可以很方便的根据 app 的功能模块定位到具体的代码。扩展性良好，如果想在此基础上再按照 MVC、MVP的模式去进一步分层，或者想在此基础上再按照类别去分层，依然可以，只需要 feature 包下某个具体的功能下面再加一层就好了。高度的模块化，也就是所谓的“高内聚”。随着 app 的迭代，如果 app 过于庞大，想要实现插件化、组件化，这种分层模式可以省不少事。

　　但是这种方式也有一些缺点，比如有些项目初期功能一直在变化，如果按照功能木块划分，会导致项目结构一直在变化。另一方面，如果项目很小，本身就没多少界面，按照这么分层感觉颗粒度太细，有点大材小用的感觉。

　　其实系统的架构设计是改善耦合的最好方式。架构设计的本质，就是划分耦合的单位（划分模块）和规范耦合的形式（代码耦合的形式有很多种，如直接调用、事件响应、消息队列等）。

　　后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下！