软件架构（五）分层架构

系列目录

软件架构（一）概览

软件架构（二）编程语言的历史

软件架构（三）名词解释：架构、设计、风格、模式

软件架构（四）单体架构(Monolithic Architecture)

软件架构（五）分层架构

软件架构（六）MVC架构历史

零几年最早接触编程时，写的课程设计就是MVC架构，这就是一种典型的分层架构。

一、分层概念

分层是一种常见的根据系统中的角色/职责拆分和组织代码单元的常规实践。注：本文说的不单指后端架构，而是整个软件的分层架构，包含前端、后端、数据库。

在一个分层系统中，每一层：

• 依赖它之下的层；
• 和它之上的层无关，对使用(依赖)它的层次无感知。

在分层架构中，分层可以访问它之下的任何分层。

二、分层历史

2.1 单层架构--20 世纪 60 年代和 70 年代

当时的应用程序和今天的应用程序截然不同。那时还没有 GUI。所有的应用程序要通过命令行使用，显示在一个哑终端里，它们实际上是单层的应用程序。如下图所示

2.2 三层架构--20 世纪 80 年代和 90 年代

在 20 世纪 80 年代，企业应用出现了，在公司里有多个用户开始使用桌面电脑通过网络访问应用。

这时它们多半分成三层：

• 用户界面(展现)：用户界面就是网页、命令行或者原生桌面应用；
  • 例如：作为(富)客户端的 Windows 应用，普通用户在桌面电脑上使用，和服务器器通信才能完成工作。客户端负责应用的流程和用户输入的校验；
• 业务逻辑(领域)：应用之所以存在的逻辑；
  • 例如：应用服务器，包含业务逻辑并从原生客户端接收请求，采取行动并将数据保存到数据存储；
• 数据源：数据的持久化机制(数据库)，或者是和其它应用之间的通信。
  • 例如：数据库服务器，应用服务器用它来完成数据持久化。

这实际上是一种 两层 应用，客户端是一个用为应用界面的富客户端应用程序，而业务逻辑和数据源放在服务器。

90年代后期，发展出真三层架构：

• 原生浏览器应用程序：渲染和运行用户界面，向服务器应用发送请求；
• 应用服务器：包括了展现层、应用层、领域层和持久化层；
• 数据库服务器：应用服务器用它来完成数据的持久化。

这就是三层架构模式，也叫 N 层架构。它是可伸缩的解决方案，尽管用户界面是在客户端浏览器中渲染和运行，但由于用户界面存放于服务器上并在服务器上编译，它“解决了客户端的更新问题”。

说实话这种架构，在国内很少用到。国内到2010年，主流都还在玩MVC。

2.3 多层架构--2003年之后DDD领域驱动设计

2003 年， Eric Evans 出版了他的标志性著作 Domain-Driven Design: Tackling Complexity in the Heart of Software。在书中提出的许多关键概念之中，也有对软件系统分层的展望：

• 用户界面

  负责绘制用户和应用交互的界面，并将用户输入转换成应用的命令。值得注意的是，“用户”可以是人类也可以是其它应用。它和 Ivar Jacobson 的 EBI 架构(后面其它文章会介绍更多细节)中的边界对象不谋而合；

• 应用层

  指挥领域对象完成用户要求的任务。它不包括业务逻辑。它和 Ivar Jacobson 的 EBI 架构中的交互器对象对应，唯一不同的是 Jacobson 的交互器可以是任意和界面或实体无关的对象；

• 领域层

  这一层包含了所有的业务逻辑、实体、事件或者其它任何包含业务逻辑的对象类型。显然它和 EBI 中的实体对象类型相对应。这是系统的心脏；

• 基础设施

  支撑上面所有层次的技术能力，如持久化机制和消息机制。

很奇怪的是，03年风靡国外的DDD，竟然在21年才开始风靡。炒了一锅冷菜。DDD理论很好，但落地是有一定难度的，具体落地可参考博客：DDD领域驱动设计落地实践（十分钟看完，半小时落地）

2.4 反模式：千层面模式

当我们过分严格遵守分层架构时，容易出现“反模式”。过度的抽象并不利于使用。记住：架构是用来用的，如果成了累赘，不要这种架构也罢。

千层面架构常常说的就是分层架构的反模式。以下这些情况发会出现：

• 热衷于创建完美的系统导致项目过度抽象；
• 小更新也会波及应用的方方面面，牵一发动全身，增强依赖性，提升了变动的风险。
• 层次太多，增加了整个系统的复杂性；
• 物理层次太多，不但增加了整个系统的复杂性，还降低了系统的性能；
• 按照UI界面切割，垂直分层来组织我们的单体，破坏了领域概念的模块化和封装。

 

==========参考=============

https://herbertograca.com/2017/08/03/layered-architecture/