分层
分层相对重要，架构在设计中要考虑分层，其核心仍然是资源+服务+应用的三大层，这样的分层仍然是SOA参考架构的核心思想。平台+应用更多地只是上面分层模式的一个变形。分层的目的是通过分层理清整个应用的构建过程，并保证了各层之间的独立设计和松耦合。
分层架构的一个重要原则是每层只能与位于其下方的层发生耦合。分层架构可以简单分为两种，即严格分层架构和松散分层架构。
在严格分层架构中，某层只能与位于其直接下方的层发生耦合；在松散分层架构中，则允许某层与它的任意下方层发生耦合。
分层架构的好处是显而易见的。首先，层间松散的耦合关系使得我们可以专注于本层的设计，而不必关心其他层的设计，也不必担心自己的设计会影响其他层，对提高软件质量大有裨益。其次，分层架构使得程序结构清晰，升级和维护都变得十分容易，要更改某层的具体实现代码时，只要本层的接口保持稳定，对其他层就可以不必修改。即使本层的接口发生变化，也只影响相邻的上层，修改工作量小且错误可以控制，不会带来意外的风险。
要保持程序分层架构的优点，就必须坚持各层间的松散耦合关系。在设计程序时，应该先划分出可能的层次，以及此层次提供的接口和需要的接口。在设计某层时，应该尽量保持层间的隔离，仅使用下层提供的接口。
分层架构的优点如下。
◎ 开发人员可以只关注某一层。
◎ 可以很容易地用新的实现来替换原有层的实现。
◎ 可以降低层与层之间的依赖。
◎ 有利于标准化。
◎ 有利于各层逻辑的复用。分层架构的缺点如下。
◎ 因为增加了中间层，所以降低了系统的性能，不过可以通过缓存机制来改善。
◎ 可能会导致级联的修改。这种修改尤其体现在自上而下的方向，不过可以通过依赖倒置来改善。
模式
模式是所有思维模式里面的一个重点，架构模式是一个通用的、可重用的解决方案，架构设计中的模式匹配就是将最终的业务域问题匹配到对应的技术实现上，即根据业务需求来挑选最适合的技术，而不是用主流和最先进的技术去反推业务。
架构设计模式一般有分层模式、客户端-服务器模式、主从设备模式、管道-过滤器模式、代理模式、P2P 模式、事件总线模式、MVC 模式、黑板模式和解释器模式，接下来简单介绍这些模式。
分层模式
分层架构的一个重要原则是每层只能与位于其下方的层发生耦合。分层架构可以简单分为两种：严格分层架构和松散分层架构。在严格分层架构中，其中一层只能与其直接下方的层发生耦合；在松散分层架构中，则允许某层与它的任意下方层发生耦合，并且要保持程序分层架构的优点，就必须坚持层间的松耦合关系。在设计程序时，应该先划分出可能的层次，以及此层次提供的接口和需要的接口。在分层设计时，尽量保持层间的隔离，上层调用下层服务只能通过接口来实现。四层架构、五层架构和六边形架构是领域驱动设计分层架构中比较经典的三种架构，下面分别对这3种架构进行讲解。
1.四层架构
四层架构的模式如图4.5所示。
图4.5
对如图4.5所示的各层解释如下。
◎ 展示层：展示用户请求返回的数据。用户可以是一个系统，不一定是使用用户界面的人。
◎ 应用层：定义系统需要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是其他系统的应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，只为下一层中的领域对象协调任务、分配工作，使它们互相协作。它没有反映业务情况的状态，却可以具有另外一种状态，为用户或程序显示某个任务的进度。
◎ 领域层：负责表达业务概念、业务状态信息及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心，领域模型位于这一层。
◎ 基础设施层：向其他层提供通用的技术能力：为应用层传递消息，为领域层提供持久化机制，为展示层绘制屏幕组件等。基础设施层还能够通过架构框架来支持4个层之间的交互模式。
2.五层架构
五层架构的模式如图4.6所示。
图4.6
对如图4.6所示的各层解释如下。
◎ 展示层：主要用于处理用户发送的Restful请求和解析用户输入的配置文件等，并将信息传递给应用层的接口。
◎ 应用层：负责多进程管理及调度、多线程管理及调度、多协程调度和维护业务实例的状态模型。在调度层收到展示层的请求后，委托环境层与本次业务相关的上下文进行处理。
◎ 环境层：以上下文为单位，将领域层的领域对象转换成合适的角色，通过角色交互起来完成业务逻辑。
◎ 领域层：定义领域模型，不仅包括领域对象及其之间关系的建模，还包括对象角色的显式建模。
◎ 基础设施层，向其他层提供通用的技术能力，例如业务平台、编程框架、持久化机制、消息机制、第三方库的封装和通用算法，等等。
3.六边形架构
六边形架构，又被称为端口和适配器风格，最早由AlistairCockburn提出，并在领域驱动设计社区得到了发展和推广。这个架构之所以是六边形形式的，是为了凸显这个架构的扁平，每个边界的权重都是相等的。
六边形架构的模式如图4.7所示。
图4.7
我们知道，经典分层架构分为三层（展示层、应用层和数据访问层），而六边形架构可以分成另外的三层，如下所述。
◎ 领域层（Domain Layer）：最内层，是纯粹的核心业务逻辑，一般不包含任何技术实现或引用。
◎ 端口层（Ports Layer）：位于领域层之外，负责接收与用例相关的所有请求，这些请求负责在领域层中协调工作。端口层在端口内部作为领域层的边界，在端口外部则扮演了外部实体的角色。
◎ 适配器层（Adapters Layer）：位于端口层之外，负责以某种格式接收输入及产生输出。比如，对于 HTTP 用户请求，适配器会将其转换为对领域层的调用，并将领域层传回的响应进行封装，通过HTTP 传回调用的客户端。在适配器层不存在领域逻辑，它的唯一职责就是在外部世界与领域层之间进行技术性的转换。适配器能够与端口的某个协议关联并使用该端口，多个适配器可以使用同一个端口，在切换到某种新的用户界面时，可以让新界面与老界面同时使用相同的端口。
这样做的好处是使业务边界更加清晰，从而获得更好的扩展性，还使业务复杂度和技术复杂度分离，是领域驱动设计的重要基础。核心的领域层可以专注于业务逻辑而不用理会技术依赖，外部接口在被消费者调用时也不用关心业务在内部是如何实现的。正如上文提到的，六边形架构的出现早于领域驱动设计，要实现领域驱动设计也不必非要采用六边形架构，只是这种架构正好契合了领域驱动设计所需的条件，从六边形架构出发，可以更容易理解领域驱动设计的思想。如图4.7所示，适配器所在的线框表示限界上下文，中间的六边形表就是应用服务，标记出核心领域模型对外暴露的功能和方法。应用层的核心就是领域模型，包含领域对象和领域服务，其中领域对象又分为实体对象和值对象，值对象中的一个特定对象就是聚合根，聚合根就是这个领域的核心。
分层模式主要用于一般的桌面应用程序和电子商务We b应用程序。
客户端-服务器模式
客户端-服务器模式简称C/S结构，是一种网络架构，它将客户端（Client）与服务器（Server）区分开来。每个客户端软件的实例都可以向一个服务器或应用程序服务器发送请求。客户服务器模式通过不同的途径应用于很多不同类型的应用程序，最常见的就是目前互联网上的网页。例如，当我们在维基百科上阅读文章时，我们的电脑和网页浏览器就被当作一个客户端，同时，组成维基百科的电脑、数据库和应用程序被当作服务器。当我们的网页浏览器向维基百科请求一篇指定的文章时，维基百科服务器会从维基百科的数据库中找出该文章的所有信息，并将这些信息结合成一个网页，再发送给我们的浏览器。
C/S模式是一个逻辑概念，不是指计算机设备。在C/S模式中，请求方叫作客户端，响应请求方叫作服务器，如果一个服务器在响应客户端请求时不能单独完成任务，则还可能向其他服务器发出请求，这时，发出请求的服务器就成为另一个服务器的客户端。从双方建立联系的方式来看，主动启动通信的应用叫作客户端，被动等待通信的应用叫作服务器。它们的通信过程如图4.8所示。
图4.8
客户端-服务器模式主要用于电子邮件、文件共享和银行等在线应用程序中。
主从设备模式
主从设备（Master-Slave）模式也叫作主仆模式，它基于分而治之的思想，将一个原始任务分解为若干个语义等同的子任务，并由专门的工作者线程并行执行这些任务，原始任务的执行结果是通过整合各个子任务的处理结果形成的。主从设备模式如图4.9所示。
图4.9
主从设备模式的使用场景如下。
◎ 在数据库的主从设计中，从库的数据是通过同步主库的数据而来的。
◎ 计算机系统中主从驱动器的设计原理。
管道-过滤器模式
管道过滤器（Pipe-And-Filter）确定了系统的架构模式，它和工业流水线一样，原材料在通过流水线上的一道道工序后，形成了某种商业产品。在管道过滤器中，一个个的过滤器会对数据进行过滤，最后得到需要的数据。
管道负责数据的传递，它将原始数据传递给第1个过滤器，将一个过滤器的输出传递给下一个过滤器，作为下一个过滤器的输入，重复这个过程，直到处理结束。需要注意的是，管道只是对数据传输的抽象，它可能是管道，也可能是其他通信方式，甚至什么都没有（所有过滤器都在原始数据的基础上进行处理）。
过滤器只负责处理数据，可以有多个，每个过滤器都对原始数据做特定的处理，它们之间没有任何依赖关系，一个过滤器不必知道其他过滤器的存在。这种松耦合的设计，使得过滤器只需要实现单一的功能来降低了系统的复杂度，也使得过滤器之间的依赖最小，从而以更加灵活的组合来实现新的功能，如图4.10所示。
图4.10
管道-过滤器模式的使用场景如下。
◎ 编译器。
◎ 生物信息学的工作流。
代理模式
代理模式用于在结构化系统中对组件进行解耦，系统内各组件之间采用远程调用的方式进行交互，代理组件充当组件间通信的协调角色，提供服务的组件将其能力（服务及特性）发布给代理，客户端均向代理请求服务，由代理将请求重定向到先前已发布过对应服务的组件进行处理，如图4.11所示。
图4.11
代理模式多用于消息代理软件中，例如ActiveMQ、Kafka、RabbitMQ和JBoss Messaging等。
P2P模式
P2P（Peer-to-Peer，点对点）是一种网络技术，依赖网络中各节点的计算能力和带宽，而不是把依赖都聚集在有限的几台服务器上。
P2P架构的核心思想是每个节点既是客户端（Client），又是服务器端（Server），如图4.12所示。
图4.12
P2P（Point to Point，点对点）是下载术语，指我们的电脑在下载的同时要继续做主机上传。在这种下载方式中，参与下载的电脑越多，下载速度越快，但是对硬盘损伤较大（在写的同时还要读），对内存占用也较多，影响整机速度。
P2P在网络隐私要求高和文件共享的领域得到了广泛应用，使用纯P2P技术的网络系统有比特币等。另外，P2P 技术也被用于类似 VoIP等实时媒体业务的数据通信中。有些网络涉及搜索的一些功能，也使用客户端-服务器结构，但使用 P2P 结构来实现另外一些功能，这种网络设计模型不同于客户端-服务器模型，在客户端-服务器模型中通信通常来往于一台中央服务器。
P2P网络主要用于让所有客户端都能提供资源，比如带宽、存储空间和计算能力。当有节点加入且对系统请求增多时，整个系统的容量也增加，这是具有一组固定服务器的客户端-服务器结构不能实现的，因为在这种结构中，客户端的增加意味着所有用户更慢速度的数据传输。P2P网络的分布特性通过在多节点上复制数据展现，这也增加了防故障的健壮性，并且在纯P2P网络中，节点不需要依靠一个中心索引服务器来发现数据，系统也不会出现单点崩溃的情况。
P2P模式的使用场景如下。
◎ 像Gnutella和G2这样的文件共享网络。
◎ 多媒体协议如P2PTV和PDTP。
◎ 像Spotify这样的专有多媒体应用程序。
事件总线模式
事件总线模式如图4.13所示。这种模式主要处理事件，包括4个主要组件：事件源、事件监听器、通道和事件总线。事件源将消息发布到事件总线的特定通道上；事件监听器订阅特定的通道，它会被通知消息，这些消息被发布到它们之前订阅的一个通道上。
图4.13
事件总线模式的使用场景如下。
◎ 安卓开发。
◎ 通知服务。
MVC模式
MVC（Model View Controller，模型-视图-控制器）的概念存在很长时间了，但是随着互联网的发展，对客户端-服务器应用的需求日益增加，它才作为最佳设计方式被更多的人熟知。所有 Web框架都基于 MVC概念构建而成。MVC设计模式的概念也非常容易理解。
◎ 模型（M）是数据的表述，它不是真正的数据，而是数据的接口。我们在使用模型从数据库中获取数据时，无须知道底层数据库错综复杂的知识。模型通常还会为数据库提供一层抽象，这样同一模型就能使用不同的数据库。
◎ 视图（V）是我们看到的界面，它是模型的表现层。在电脑中，视图是我们在浏览器中看到的We b应用的页面，或者桌面应用的UI。视图还提供了收集用户输入的接口。
◎ 控制器（C）控制模型和视图之间的信息流动。它通过程序逻辑来判断模型从数据库中获取了什么信息，以及将什么信息传给了视图。它还通过视图从用户那里收集信息，并且实现业务逻辑、变更视图，或者通过模型修改数据，抑或二者兼具。MVC模式如图4.14所示。
图4.14
MVC模式的使用场景如下。
◎ 互联网应用程序的体系架构。
◎ 像Django和Rails这样的Web框架。
黑板模式
黑板模式是一种常用的架构模式，是对观察者模式的扩展，由3个主要部分组成，如图4.15所示。
图4.15
◎ 知识源：包含与应用程序相关的独立信息，信息源之间不直接进行通信，它们之间的交互只通过黑板完成。
◎ 黑板数据：黑板数据指按照与应用程序相关的层次来组织并解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
◎ 控制：完全由黑板的状态驱动，黑板状态的改变决定了我们需要使用的特定知识。
所有组件都可以访问黑板。组件可以生成添加到黑板上的新数据对象，它在黑板上查找特定类型的数据，并通过与现有知识源的模式匹配来查找这些数据。
黑板模式的使用场景如下。
◎ 语音识别。
◎ 车辆识别和跟踪。
◎ 蛋白质结构识别。
◎ 对声呐信号的解释。
解释器模式
解释器模式属于行为型模式，实现了一个表达式接口，该接口解释一个特定的上下文，常用于符号处理引擎、SQL解析等中。解释器模式如图4.16所示。
图4.16
下面对如图4.16所示的名词进行解释。
◎ 抽象表达式角色（Expression）：声明所有的具体表达式角色都需要实现的一个抽象接口。这个接口主要是一个interpret（）方法，叫作解释操作。
◎ 终结符表达式角色（Terminal Expression）：实现了抽象表达式角色所要求的接口，主要是一个interpret（）方法；文法中的每一个终结符都有一个具体的终结表达式与之对应。比如有一个简单的公式R=R1+R2，其中的R1和R2就是终结符，对应的解析R1和R2的解释器就是终结符表达式。◎ 非终结表达式角色（Nonterminal Expression）：文法中的每一条规则都需要一个具体的非终结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如在公式R=R1+R2中，“+”就是非终结符，解析“+”的解释器就是一个非终结符表达式。
◎ 环境角色（Context）：这个角色的任务一般是存放文法中各个终结符所对应的具体值，比如R=R1+R2，我们给R1赋值100，给R2赋值200，这些信息都需要被存放到环境角色中，在很多情况下我们使用Map来充当环境角色就够了。
解释器模式的使用场景如下。
◎ 数据库查询语言，比如SQL。
◎ 用于描述通信协议的语言。
本文给大家讲解的内容是程序员架构修炼：架构思维的动静分层与模式
- 下篇文章给大家讲解的是程序员架构修炼：架构思维的抽象、结构化 、迭代、勿做过度设计；
- 觉得文章不错的朋友可以转发此文关注小编；
- 感谢大家的支持！
