单实例模式、仓库模式、工厂模式、生成器、装饰模式(decorator )……恐怕任何一门课上的程序员都不知道
软件体系结构中也存在类似的机制，这是特定上下文中的软件体系结构经常出现的常见可重用解决方案的问题。 软件体系结构模型各不相同。 以下是目前主流的五种软件体系结构模型。
“层模式”) ) )。
分层模型可能是最有名的软件体系结构模型之一，许多开发人员都在使用，但不知道其名称。 分层模式将代码划分为“分层”，每个分层负责，并为更高的“分层”提供服务。
层次结构模型没有规定层次结构的数量，但通常结构如下：
表示层/UI层APP应用层业务/域(domain )层持久化/数据访问层数据库层的分层模型的想法是，用户通过执行某些操作(例如单击按钮)来进行表示然后，表示层调用APP应用层，进入业务层，最后持久层将所有内容存储在数据库中。 简单地说，分层模式的上层调用下层并依赖。
根据应用的复杂性，可以看到很多对应的变化。 例如，有些APP可能省略APP应用层，有些APP可能添加缓存层，或者两层集成在一起。
层责任
如上所述，各层有各层的责任。 演示层包含了APP的图形设计和处理交互的代码。 理论上，不应该向该层添加与用户界面无关的逻辑。
业务层是放置特定业务问题模型和逻辑的地方。
APP层介于业务层和性能层之间。 一方面为表现层提供业务层的抽象，另一方面为APP层提供不适于置于业务层和表现层的调整逻辑。
持久层包含访问数据库层的代码，数据库层是SQL Server、MongoDB等基础数据库技术。 持久层是用于处理数据库的代码集，如SQL语句、连接详细信息等。
好处
大多数开发者都熟悉创建有组织、可测试的APP的简单方法的缺点
分层模式往往会导致APP的“整合”，使开发者难以分割。 您会发现，在大多数情况下，您编写了许多代码来传递不同的层，而无需向这些层添加值。 如果只是创建简单的crud APP，分层模式可能有点过头了。 适用于
标准的、不仅用于完成CRUD操作的基干业务(line-of-business )应用微内核模式(Microkernel ) )。
如果APP应用程序具有一组核心角色和可交换部件，则微内核模式(或插件模式)非常有用。 微内核提供了APP应用的入口点和常规流程，而不需要实际了解各种插件在做什么。
例如任务调度，微内核可以包含所有的调度和触发逻辑，插件负责特定的任务。 只要插件遵循特定的API，微内核就可以不知道实现的详细情况就从它们出发。
另一个例子是工作流。 工作流的实施包括不同步骤的顺序、评估步骤后决定下一步骤的内容等概念，步骤的具体实施对工作流的核心代码并不重要。
好处
灵活的可扩展性的一些实现使不同的团队能够通过在APP运行时添加插件微内核和插件来开发劣势
很难确定微内核的预定义API可能不适用于未来的插件
从不同的源获取数据，转换数据，然后写入不同位置的APP工作流APP任务和作业调度APP命令角色查询分离模式(CQRS ) )
CQRS是commandandqueryresponsibilitysegregation的缩写。 该模型的核心概念是应用完全分离的读取和写入操作，这意味着用于写入操作(命令)的模型和读取(查询)不同。 另外，数据保存在别的地方。 这意味着关系数据库中存在用于命令模型的表和用于读取模型的表。 在某些实现中，可能会将不同的模型(如用于命令模型的SQL服务器或用于导入模型的MongoDB )存储在完全不同的数据库中。
CQRS模式通常与“事件跟踪”(Event Sourcing )一起在下一节中进行说明。
CQRS是如何工作的？ 当使用者执行作业时，APP应用程式会将指令传送到指令伺服器。 命令服务从命令数据库获取必要的数据，进行必要的操作，保存到数据库中，然后通知读取服务更新读取模型。 如下所示。
如果APP需要向用户显示数据，则可以通过调用读取服务来获取读取模型，如下所示：
pgc-image/1537845259023eb07d97bf8?from=pc">优势
命令模型专注于业务逻辑和验证，读取模型根据特定情境进行定制可以避免复杂的查询，让读取更高效劣势
保持命令和读取模型同步可能会让事情变得很复杂适用于
需要大量读取的应用有复杂域的应用事件溯源模式（Event Sourcing）
这种模式不会将模型的当前状态存储在数据库中，而是将时间存储其中。因此，例如customer name发生变化时，该值不会存储在“name“列中，我们会存储一个”NameChanged“事件。
当我们需要检索模型时，我们将检索其存储的所有事件并在新对象上重新应用，即rehydrating an object。
用EXCEL记账来理解event sourcing会容易一些。当我们添加支出时，我们不需更改总值，而是增加一“行”，出现错误，也增加一“行”，最终利用EXCEL的公式自动计算出总数，而这里计算总数可以看作是读取模型。
您可以看到我们在添加Invoice 201805时发生了错误。我们添加了两条新行，而不是更改行，首先是一行取消错误的行，然后是新的正确行。这就是event sourcing的工作方式。你永远不会删除事件，因为它们无可否认地发生在过去。为了纠正情况，我们添加了新事件。
另外，请注意我们是如何获取总值的，它是上面单元格中所有值的总和。在Excel中，它会自动更新，因此我们可以说它与其他单元格同步。这就是一个读取模型。
Event sourcing通常会与CQRS同时使用，因为rehydrating an object可能会对性能产生影响，尤其是当实例中存在大量事件时。快速读取模型可以显着改善应用的响应时间。
优势
提供“开箱即用”的audit log，每个事件即特定时间点上的特定操作劣势
event sourcing有一定的限制要求，我们不能直接通过数据库中的简单编辑来修复错误数据改变事件的结构比较复杂适用于
需要发布事件到外部系统的应用CQRS应用有复杂域的应用需要数据修改audit log的应用微服务模式（Microservices）
编写一组微服务实际上就是编写可以协同的多个应用。每个微服务都有自己独特的责任，团队可以独立于其他微服务开发它们。他们之间唯一的依赖是通信。当微服务相互通信时，我们必须确保它们之间发送的消息保持backwards-compatible（向后兼容）。这需要一些协调，特别是当不同的团队负责不同的微服务时。
如下图所示——
在上图中，应用调用一个中央API，将调用转发给正确的微服务。在此示例中，有为用户配置文件、库存、订单和付款提供单独的服务。我们可以想象这是一个用户订购应用。单独的微服务也可以相互调用。例如，支付服务可以在支付成功时通知订单服务。然后，订单服务可以调用库存服务来调整库存。
没有明确规定微服务有多大。在前面的示例中，用户配置文件服务可能负责用户的用户名和密码等数据，也可能负责家庭地址、头像图像、收藏夹等，也可以选择将所有这些责任分成更小的微服务。
优势
我们可以单独编写、维护、部署微服务微服务架构容易扩展重写变得很容易，因为微服务之间松耦合劣势
实际上没有合适的工具平台，反而在沉默的裙子编写结构良好的一体化应用，再拆分为微服务的办法实际上更容易。使用微服务，会产生许多额外的问题：通信、协调，向后兼容、日志记录等。没有编写结构良好的整体结构的必要技能的团队可能很难编写一组良好的微服务。传统微服务架构可能会有多个失败点，查找问题可能会比较复杂适用于
某些组件被密集使用并需要扩展的应用为其他应用提供功能的应用一体化架构下很复杂的应用能够明确定义bounded contexts的应用总结
各种软件架构模式很多时候会结合起来使用，他们之间并没有我们想象得那么水火难容。换句话说，没有万能的软件架构模式，如何选择取决于我们对于解决方案利弊的权衡。