软件架构：5种你应该知道的模式

Singleton（单例模式）、仓储模式（repository）、工厂模式（factory）、建造者模式（builder）、装饰模式（decorator）……大概每个上课听讲的程序员都不会陌生——软件的设计模式为我们提供了针对现有的、重复出现的问题以可靠的解决方案。

在软件架构方面同样存在类似的机制，通用的、可重用的解决方案在给定上下文中的软件体系结构中经常出现的问题。不同的软件架构模式各有千秋，以下是目前较为主流的5种软件架构模式。

分层模式（Layered Pattern）

分层模式大概是最知名的软件架构模式之一，有大量的开发者使用，但并不知道它的名字。分层模式将代码拆分为“层”，每个层都有一定的责任，并为更高“层”服务。

分层模式并没有规定层的数量，但通常会有以下结构：

• 表现层 / UI层
• 应用层
• 业务/域（domain）层
• 持久/数据访问层
• 数据库层

分层模式的想法是用户通过执行某些动作（例如点击按钮）在表现层启动一段代码。随后，表现层调用应用层、进入业务层，最后持久层将所有内容存储在数据库中。简单来说，分层模式中的高层调用并依赖低层。

根据应用复杂程度，我们会看到很多相应的变体。例如某些应用会省略应用层，而某些应用会添加缓存层，甚至会出现两层合一的情况。

层责任

如上所述，每层有每层的责任。表现层包含应用的图形设计和处理交互的代码。理论上来讲，我们不应该在这一层添加任何与user interface无关的逻辑。

业务层是放置特定业务问题模型和逻辑的地方。

应用层位于业务层和和表现层之间。一方面为表现层提供业务层抽象，另一方面为应用层提供放置某些不适合放置于业务层或表现层的某些协调逻辑。

持久层包含访问数据库层的代码，而数据库层是底层数据库技术，例如SQL Server、MongoDB。持久层是用于操作数据库的代码集：SQL语句、连接详情等。

优势

• 大多数开发者都很熟悉
• 一种用于编写组织良好并且可测试应用的简单方法

劣势

• 分层模式往往会导致应用的“一体化”并使之变得难以拆分
• 开发者往往会发现自己编写了大量的代码来传递不同的层，而没有在这些层里添加任何值。如果我们做的只是编写一个简单的CRUD应用，分层模式可能有点过分了。

适用于

• 标准的、不仅仅用于完成CRUD操作的业务线（line-of-business）应用

微内核模式（Microkernel）

当应用程序有一组核心职责和一组可互换的部件时，微内核模式(或插件模式)非常有用。微内核将提供应用程序的入口点和一般流程，而不需要真正了解不同的插件在做什么。

例如任务调度，微内核可以包含所有的调度和触发逻辑，而插件负责特定的任务。只要插件遵循特定的API，微内核就可以出发它们，而不需要了解实现的细节。

另一个例子是工作流。工作流的实现包含诸如不同步骤的顺序、评估步骤的结果、决定下一步的内容等概念，步骤的的具体实现对于工作流的核心代码并不重要。

优势

• 灵活性