架构之道：界定的责任与模块划分

分层架构模式，不仅广泛应用，还是管理复杂系统的利器。这一模式灵感来源于《Clean Architecture》，常被形象比喻为“洋葱架构”。分层架构描述系统就像洋葱一样，一层层叠加，每层都有各自的职责和功能。这种设计让责任和模块的分工变得非常明确。 具体来说，在这样的架构里，每一层都专注于承担特定的职责。拿核心的“用例”层来说，这里面藏着应用的核心业务逻辑，而且这些逻辑与用户界面和数据库无关。这种清晰的职责分配不仅方便了业务逻辑的维护和扩展，也使得测试和调试过程更加简单。 通过把关注点分散到不同的层次，我们其实为系统的每个部分设定了明确的边界和接口。这不仅让系统的结构更加有序，还提高了代码的可复用性和可维护性。例如，在Java EE项目中，分层架构因其清晰的结构划分而成为开发的标准，广受开发者和架构师的欢迎。 1、分层模式概述 在分层架构模式中，我们将应用程序的各个组成部分有序地分为水平层，每个层次都承担着明确定义的职责，例如呈现逻辑或业务逻辑。尽管分层架构模式没有规定必须包含多少层或具体类型的层，但大多数分层架构都包括四个基本层次：表示、业务、持久化和数据库（如图5-2所示）。有些情况下，业务层和持久化层会融合成一个单一的业务层，尤其是当将持久化逻辑（如SQL或HSQL）嵌入到业务层组件中时。因此，小型应用可能只有三个层，而更大、更复杂的业务应用可能包含五个或更多层。

每个分层架构模式的层次都有明确的角色和职责。例如，表示层负责处理用户界面和浏览器通信逻辑，而业务层则负责执行与请求相关的具体业务规则。架构的每个层次都形成了关于满足特定业务请求所需工作的抽象。举个例子，表示层不需要关心如何获取客户数据，它只需以特定格式在屏幕上展示信息。同样，业务层不需要担心如何将客户数据格式化以在屏幕上显示，也不需要知道客户数据来自何处；它只需要从持久化层获取数据，执行业务逻辑（如计算值或汇总数据），然后将信息传递给表示层。 分层架构模式的一个强大特点是实现了"关注点分离"，每个层次中的组件只处理与该层相关的逻辑。例如，表示层中的组件仅处理呈现逻辑，而业务层中的组件仅处理业务逻辑。这种组件分类方式使得能够轻松地在架构中构建有效的角色和职责模型，同时由于明确定义的组件接口和有限的组件范围，使用这一架构模式进行应用程序的开发、测试、管理和维护也变得更加容易。 2、封闭层次与隔离层 如图5-3所示，我们强调了架构中的一个至关重要的概念，即"封闭层"。这个概念是分层架构设计的核心要素之一。"封闭层"的含义是，请求在不同层之间传递时必须按照从上往下的顺序逐层经过，才能到达目标层。举例来说，如果一个请求起初来自表示层，它必须首先通过业务层，然后才能到达持久化层，最终访问数据库层。 为什么不允许表示层直接访问持久化层或数据库层呢？毕竟，直接从表示层访问数据库似乎更高效。答案在于另一个关键概念，即"隔离层"。 "隔离层"的思想是，对架构中的某一层所做的更改通常不应该对其他层的组件产生影响。这意味着变更应该受限于某一层内的组件，并可能涉及到另一层（例如，涉及到包含SQL的持久化层）。如果允许表示层直接访问持久化层，那么持久化层中的SQL更改将波及到业务层和表示层，导致这些组件之间紧密耦合，从而使架构难以维护和修改，成本高昂。

"隔离层"的思想还意味着每个层都应该独立于架构中的其他层，几乎不需要了解其他层内部的工作方式。要理解这个概念的重要性，可以考虑一个大规模的重构工作，将呈现框架从JSP（Java Server Pages）转换为JSF（Java Server Faces）。假设用于表示层和业务层之间的协议（例如，模型）保持不变，那么业务层不受这项重构的影响，它仍然与用户界面框架的类型无关。 3、开放层与封闭层 虽然封闭层有助于实现隔离层，从而帮助架构内部的变更隔离开来，但有时候保持某些层次是"开放"也是合理的。例如，假设您希望向架构中包含业务层组件的通用服务组件添加一个共享服务层（例如，数据和字符串工具类或审计和日志记录类）。在这种情况下，通常会创建一个"开放层"，因为它可以限制对共享服务的访问仅限于业务层，而不是表示层。如果没有这个独立的层，架构上没有明确的机制来限制表示层对这些共享服务的访问，这会使限制这种访问变得困难。 在这个示例中，新的服务层很可能位于业务层下方，以表示该服务层中的组件不应该直接从表示层访问。然而，这引发了一个问题，即业务层现在需要通过服务层才能访问持久化层，这似乎没有道理。这是分层架构中的一个老生常谈，可以通过在架构内部创建"开放层"来解决。 如图5-4所示，这种情况下的服务层被标记为"开放"，这意味着请求允许绕过该层，直接到达下方的层。在这个示例中，由于服务层是"开放"的，业务层现在可以绕过服务层，直接访问持久化层，这是合理的。

充分利用"开放"和"封闭"层的概念有助于明确定义架构层之间的关系和请求流程，为设计师和开发人员提供了必要的指导，以了解架构内各层的访问限制。如果不充分记录或适当传达架构中的层次（以及为什么如此），通常会导致紧密耦合和脆弱的架构，这些架构非常难以测试、维护和部署。 4、分层模式示例 为了解释分层架构的操作方式，让我们以一个业务用户的需求为例，他们想要获取特定个人客户的信息，就如图5-5所展示的那样。在图中，我们使用黑色箭头表示请求的流向，请求从上游传递到数据库以检索客户数据；而红色箭头表示响应的流向，数据从下游传递回屏幕以供用户查看。在这个示例中，客户信息包括客户数据和订单数据（这些订单是由该客户下单的）。 客户端界面的任务是接收请求并呈现客户信息。它不需要知道数据的具体位置、数据如何被检索，或者需要查询多少个数据库表来获取数据。一旦客户端界面接收到特定个体客户信息的请求，它将请求转发给客户代理模块。客户代理模块负责了解业务层中哪些模块能够处理该请求，如何到达这些模块，以及需要哪些数据（也就是契约）。在业务层，客户对象负责汇总业务请求所需的所有信息（在这个案例中，就是获取客户信息）。这个模块会调用持久化层中的客户数据访问对象（DAO）模块，以获取客户数据，同时还会调用订单DAO模块，以获取订单信息。这些模块接着会执行SQL语句，以检索相应的数据，并将数据传递回业务层中的客户对象。一旦客户对象接收到数据，它会汇总这些数据，并将信息传递回客户代理，然后再将数据传递给客户屏幕，以供用户查看。

从技术的角度来看，这些模块可以有多种不同的实现方式。例如，在Java平台上，客户屏幕可以是（JSF）Java Server Faces屏幕，结合客户代理作为托管Bean组件。业务层中的客户对象可以是本地Spring Bean，或者远程EJB3 Bean。如前所述的数据访问对象可以被实现为简单的POJO（Plain Old Java Objects）、MyBatis XML Mapper文件，甚至是封装原始JDBC调用或Hibernate查询的对象。从微软平台的视角来看，客户端界面可以是一个使用.NET框架的ASP（活动服务器页面）模块，用于访问业务层中的C#模块，而客户和订单数据访问模块可以实现为ADO（ActiveX Data Objects）。 5、注意事项 分层架构模式是一种坚实而通用的设计模式，特别适用于大多数应用程序，尤其是在您不确定哪种架构模式最适合您的应用时，它是一个很好的起点。然而，在选择这种模式时，从架构的角度有一些需要考虑的要点。 首要要注意的是架构中的“吞噬陷阱”反模式。这一反模式描述了一种情况，即请求在架构的多个层中以简单的透传方式进行处理，每个层几乎没有或根本没有执行逻辑。例如，假设呈现层响应用户的请求以检索客户数据。呈现层将请求传递给业务层，而业务层只是将请求传递给持久化层，后者再向数据库层发出简单的SQL调用以检索客户数据。然后数据沿着堆栈原路返回，没有任何额外的处理或逻辑来汇总、计算或转换数据。 几乎每个分层架构都会涉及到某种程度的架构“吞噬陷阱”反模式。然而，关键在于分析落入此类情况的请求比例。通常，遵循80-20法则是一个不错的实践，以确定是否存在架构“吞噬陷阱”反模式。通常情况下，大约有20%的请求是简单的透传处理，而有80%的请求涉及某种业务逻辑。但是，如果发现这一比例反转，即大多数请求都是简单的透传处理，那么您可能需要考虑将某些架构层开放，尽管要牢记由于层次隔离不足而更难控制变更。 另一个需要考虑的因素是，尽管将呈现层和业务层拆分为独立的可部署单元，但分层架构模式往往倾向于形成单块式应用程序。尽管这对某些应用程序可能不构成问题，但在部署、整体健壮性与可靠性、性能以及可扩展性方面可能会引发一些潜在问题。 6、模式分析 根据表5-1的数据，我们可以看出，分层架构模式在各个方面都有不同的特点和评级。总体敏捷性和部署的便捷性方面的评级较低，这表明该模式在迅速应对变化和方便部署方面存在挑战。然而，可测试性方面评级较高，因为分层结构使得组件易于模拟和测试。性能评级较低，这是因为必须经过多个层来满足业务请求，可能导致效率问题。可扩展性方面也评级较低，通常情况下，该模式倾向于紧密耦合和单块式实现，导致扩展成本较高。最后，开发的便捷性评级较高，因为分层架构模式广为人知且不过于复杂，适合大多数业务应用程序的开发。因此，在选择是否采用分层架构模式时，需要综合考虑这些特点，根据具体应用的需求和情况做出明智的决策。 表5-1 分层模式特征及评级

7、小结 分层架构作为一种经典和直观的设计模式，尤其适合规模适中（用户数少于100-200）且预计上线后需求变化不大的应用程序。它通过将复杂系统分解为互相协作但相对独立的层次，不仅降低了实施难度，而且在成本效益上具有明显优势。 优势详解

• 测试的便捷性：分层架构的一大亮点是其组件清晰地分配到不同的层次中，使得每个组件都可以独立进行测试。这种分离确保了测试过程的高效性和准确性，因为问题可以快速定位到特定的层。
• 设计的自然流畅性：考虑到大多数应用程序本质上都是层次化的，分层架构提供了一种符合直觉的设计方式。它不仅容易理解和实施，而且与应用程序的自然结构相契合，为开发人员创建出直观易懂的设计蓝图。

面临的挑战

• 灵活性受限：虽然分层架构在理论上支持对特定层的修改，实际上，应用被视作一个整体单元，这使得任何变更都较为复杂。层之间的紧密耦合进一步增加了修改的难度，也使得应用的扩展性受到限制。
• 部署的制约：在分层架构中，应用需作为单一单元部署，这意味着即便是微小的更改，也需重新部署整个系统。这种方法在某些情况下可能导致效率低下。
• 性能的挑战：随着应用规模的扩大，处理请求需穿过多层，每一层都可能增加资源消耗。这不仅可能导致性能下降，而且在高负载情况下，响应时间可能变得不可预测。