本文共 2283 字，大约阅读时间需要 7 分钟。

软件架构模式（Software Architecture Pattern）是Mark Richards编写的介绍各种软件架构设计模式的书，目的是给架构师足够的信息去做出正确的架构决策。

1 简介

应用程序缺乏合理的架构一般会导致程序过度耦合、容易被破坏、难以应对变化，同时很难有一个清晰的版本或者方向性。这样的结果是，如果你没有充分理解程序系统里每个组件和模块，就很难定义这个程序的结构特征。有关于程序的部署和维护的基本问题都难以回答，比如：程序架构是什么规模?应用程序有什么性能特点?应用程序有多容易应对变化?应用程序的部署特点是什么?架构是如何反应的?

架构模式帮助你定义应用程序的基本特征和行为。例如，一些架构模式会让程序自己自然而然地朝着具有良好伸缩性的方向发展，而其他架构模式会让程序朝着高度灵活的方向发展。知道了这些特点，了解架构模式的优点和缺点是非常必要的，它帮助我们选择一个适合自己特定的业务需求和目标的的程序。

作为一个架构师, 你必须证明你的架构模式的决策是正确的,特别是当需要选择一个特定的体系结构模式或方法的时候。这本书的目的就是给出足够的信息让你去做出正确的架构决策。

这本书主要介绍了分层架构，事件驱动架构，微内核架构，微服务架构和基于空间的架构这五种架构模式。下表是这五种架构模式优缺点的比较。

2 分层架构

分层架构模式里的组件被分成几个平行的层次，每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种，大多数的结构都分成四个层次: 展示层，业务层，持久层和数据库层。

分层架构中的每一层都有特定的角色和职能。举个例子，展示层负责处理所有的界面展示以及交互逻辑，业务层负责处理请求对应的业务。架构里的层次是具体工作的高度抽象，它们都是为了实现某种特定的业务请求。比如说展示层并不需要关心怎样得到用户数据，它只需在屏幕上以特定的格式展示信息。业务层并不关心要展示在屏幕上的用户数据格式，也不关心这些用户数据从哪里来。它只需要从持久层得到数据，执行与数据有关的相应业务逻辑，然后把这些信息传递给展示层。

关注点分离

分层架构的一个突出特性是组件间关注点分离(separation of concerns)。一个层中的组件只会处理本层的逻辑。比如说，展示层的组件只会处理展示逻辑，业务层中的组件只会去处理业务逻辑。

层隔离

分层架构的另一个特点是层隔离。层隔离就是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。

污水池反模式

使用此模式需要注意的问题是污水池反模式 (architecture      sinkhole   anti-pattern)。在这个模式中，请求流只是简单的穿过层次，不留一点云彩。比如说界面层响应了一个获得数据的请求。响应层把这个请求传递给了业务层，业务层也只是传递了这个请求到持久层，持久层对数据库做简单的SQL查询获得用户的数据。这个数据按照原理返回，不会有任何的二次处理，返回到界面上。

每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。80-20原则可以帮助你确定架构是否处于反污水模式。大概有百分之二十的请求仅仅是做简单的穿越，百分之八十的请求会做一些业务逻辑操作。然而，如果这个比例反过来，大部分的请求都是仅仅穿过层，不做逻辑操作。那么开放一些架构层会比较好。不过由于缺少了层次隔离，项目会变得难以控制。

技术实现

从技术的角度来说，有很多的方式能够实现这些模块。比如说在Java平台中，customer screen对应的是(JSF)     Java         Server Faces, 用bean组件来实现customer delegate。用本地的Spring bean或者远程的EJB3   bean来实现业务层中的customer object。数据访问可以用简单的POJP's(Plain     Old   Java Objects)，或者可以用MyBatis，还可以用JDBC或者Hibernate查询。

分层架构的优劣势分析

转载地址：https://blog.csdn.net/lclfans1983/article/details/115693676 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！