2月10日总结

三章：分层架构

传统的IT团队结构按照技术领域进行组织，例如演示团队、后端开发团队和数据库团队等。由于大多数架构师、设计师和开发人员对这种结构非常熟悉，分层架构成为大多数商业应用程序开发项目的自然选择。然而，就像所有架构风格一样，它具有优点和缺点，并不适用于所有系统。

描述

在分层架构风格中，组件被组织成水平层，每个层在应用程序中扮演特定角色，例如展示逻辑、业务逻辑和持久化逻辑。尽管层数可能有所不同，但大多数分层架构由四个标准层组成：展示、业务、持久化和数据库（见图3-1）。在某些情况下，业务层和持久化层会合并为一个单一的业务层，特别是当将持久化逻辑（如SQL）嵌入到业务层组件中时。因此，在较小的应用程序中可能只有三个层，并且较大且更复杂的商业应用程序可能包含五个或更多的层。

Figure 3-1. The layered architecture style is a technically partitioned

architecture

分层架构风格的每一层在应用程序中都扮演着特定的角色和责任。例如，表示层负责处理用户界面和浏览器通信逻辑，而业务层则负责执行与请求相关的具体业务规则。架构中的每一层都形成了一个抽象概念，围绕满足特定业务请求所需完成的工作展开。例如，表示层无需关注如何获取客户数据；它只需要以特定格式将信息呈现在屏幕上。同样地，业务层不必关心如何将客户数据格式化为显示在屏幕上或者客户数据来自哪里；它只需要从持久化层获取数据，在数据上执行业务逻辑（比如计算值或聚合数据），并将结果传递给表示层。

通常，层次结构通过命名空间、包结构或目录结构来体现（取决于所使用的实现语言）。例如，在业务层中，客户功能可以表示为app.business.customer，而在展示层中，客户逻辑将表示为app.presentation.customer。在这个例子中，命名空间的第二个节点代表了层级，而第三个节点代表了领域组件。请注意，在所有层级上都重复出现的命名空间的第三个节点（customer）揭示了一种技术上分区的架构方式，在该架构下领域被分散到各个层级。

分层架构风格的一个强大特点是组件之间的关注点分离。特定层中的组件仅处理与该层相关的逻辑。例如，表示层中的组件专注于处理表示逻辑，而业务层中的组件则专注于处理业务逻辑。这种明确划分使得在体系结构中轻松构建有效角色和责任模型，并且当使用明确定义了各个层之间接口和契约时，使用此架构风格进行应用程序开发、测试、管理和维护也变得更加便捷。
关键概念

在这种架构风格中，层可以是开放的或封闭的。请注意图3-2中标记为封闭的每个层次。封闭的层意味着当请求从一个层次移动到另一个层次时，它必须通过下面的一层才能到达下面的下一层。例如，源自表示层的请求必须首先经过业务逻辑层，然后再经过持久化层最终到达数据库层。

那么为什么不允许表示层数直接访问持久化或数据库层数呢？毕竟，从表示曾直接访问数据库比通过一堆不必要的中间步骤来检索或保存数据库信息要快得多。对于这个问题的答案在于一个关键概念——隔离性分级。

隔离层概念意味着在架构的一个层次中进行的更改通常不会影响或干扰其他层次的组件。这种变化仅限于该层内部的组件，可能还包括与之关联的另一层（例如持久化层中包含SQL语句）。如果允许表示层直接访问持久化层，则对持久化层中SQL语句所做的更改将同时影响业务逻辑和表示层，从而导致应用程序具有高度耦合性和大量组件间相互依赖性。这种类型的架构则变得脆弱，并且很难且昂贵地进行修改。

Figure 3-2. With closed layers, the request must pass through that layer

隔离层概念指的是每个层都是相互独立的，因此对于架构中其他层的内部工作几乎没有或者完全没有了解。为了更好地理解这一概念的力量和重要性，可以考虑一个大型重构项目，将演示框架从angular.js转换为react.js。假设在演示层与业务层之间使用的合同（例如模型）保持不变，则业务层不会受到重构影响，并且仍然完全独立于所使用的用户界面框架类型。同样适用于持久化层：如果设计得当，在将关系数据库替换为NoSQL数据库时只会影响到持久化层，而不会对演示或业务层产生任何影响。

尽管封闭的层可以实现隔离层次，从而有助于在架构中隔离变化，但有时候某些层开放也是合理的。例如，假设您想向包含业务层内组件访问的共享服务功能（如数据和字符串工具类或审计和日志记录类）的架构添加一个共享服务层。在这种情况下，创建一个服务层通常是明智之举，因为它从架构上限制了对共享服务仅限于业务层（而不是展示层）。如果没有单独一层，则无法在架构上限制展示逻辑访问这些公共服务，使得管理此访问限制变得困难。

在共享服务层示例中，该层可能位于业务逻辑之下以表示该服务只能被业务逻辑所访问。然而，在这里存在一个问题：业务逻辑不应该需要通过服务护盾才能到达持久性存储区域。这是分布式系统设计中经典的问题，并且可以通过创建开放式护盾来解决。

如图3-3所示，在本例中，由于服务模块是开放式的，因此可以绕过它并直接到达持久性存储模块，这样做是合理的。