每个软件项目都是不同的，但这并不意味着我们没有可以挑选的趋势。

大泥球(Big Ball of Mud)

当您不选择架构时，您最终会得到 "Big Ball of Mud" 架构。泥泞的“大球”是指从一个没有计划如何构建他们的解决方案的团队中出现的非结构化的意大利面条式代码库。

Big Ball of Mud 的名字来源于无组织的耦合和调用模式的网络，这些模式代表了没有清晰架构的项目.

分层架构

最简单和最常见的架构风格之一是分层架构。代码按技术领域划分为离散层。这清楚地表明了代码所属的位置。

将代码库典型地分解为层
一个典型的规则是每一层都是封闭的，这意味着它只能被它旁边的层访问，这有助于防止耦合。每一层都可以作为一个整体部署在一起，也可以单独部署。通常，表示层（UI）和数据库将分别部署到代码的其余部分。

管道架构

流水线架构以两种类型的单元为中心；管道和过滤器：

过滤器是独立的无状态计算单元。他们应该专注于完成一项特定任务。过滤器可以生成、测试、转换或使用数据。

管道是过滤器之间的通信通道。它们是一种方式，用于从过滤器构建管道。

微内核架构（插件架构）

微内核架构基于构建核心系统的想法，该系统包含系统完成其核心目的所需的最少功能。然后通过独立插件提供附加功能。想想 VS Code：基本应用程序非常有限，但通过添加插件，您可以使应用程序非常强大，并为您和您的项目量身定制。

通常，插件彼此隔离，因此彼此分离。他们也有独立的存储。插件可以是具有核心系统的单体的一部分，也可以单独部署。如果与插件的通信是通过某种标准化形式的消息（如 REST）完成的，则无需要求所有内容都使用相同的语言编写。

基于服务的架构

在此体系结构中，功能由基于域的服务划分。该服务可以共享数据库和用户界面，但彼此独立运行。

服务可以相互独立部署。可以为需求较高的服务提供更多资源或进行复制。还可能有一个 API 代理将请求从 UI 路由到正确的服务。

事件驱动架构

事件驱动系统对用户界面或内部发生的事件做出“反应”。这种系统是由事件处理器构建的；小的独立计算单元。通过系统的事件流可以以两种不同的方式发生。

在代理拓扑下，没有对事件处理的集中控制。每个处理器都可以广播自己的事件以触发另一个处理器形成事件链。不需要管理特定事件处理器或执行步骤之间的连接。

在中介拓扑下有一些中央控制。事件调解器控制调用哪些处理器以及事件进入系统时的顺序。可能有多个事件中介以并行或分层方式工作。

微服务架构

微服务系统由许多可独立部署的、以领域为中心的服务构建而成。“微”来自于每个服务应该只专注于完成一项任务的事实。微服务通常使用 REST 之类的东西（可能通过 API 网关）进行通信，用不同的语言编写并具有独立的存储。

微服务通常是独立部署的。这是一个“云原生”架构，它使用弹性来提供性能和可用性。

Clean Architecture

域层：实体+用例+网关协议
数据层：网关实现+ API（网络）+数据库
表示层：视图模型+视图+导航器+场景用例

实体

实体封装了企业范围内的关键业务规则。实体可以是带有方法的对象，也可以是一组数据结构和函数。只要实体可以被企业中的许多不同应用程序使用，都没有关系。-清洁架构：软件结构和设计手工艺指南（Robert C. Martin）

实体是简单的数据结构：

struct Repo {
    var id = 0
    var name = ""
    var fullname = ""
    var urlString = ""
    var starCount = 0
    var folkCount = 0
    var avatarURLString = ""
}

用例

用例层中的软件包含特定于应用程序的业务规则。它封装并实现了系统的所有用例。这些用例协调了进出实体的数据流，并指示这些实体使用其关键业务规则来实现用例的目标。-清洁架构：软件结构和设计手工艺指南（Robert C. Martin）

UseCases是执行一项特定操作的协议：

protocol GettingRepos {
    var repoGateway: RepoGatewayType { get }
}

extension GettingRepos {
    func getRepos(_ dto: GetPageDto) -> Observable<PagingInfo<Repo>> {
        repoGateway.getRepos(dto)
    }
}

数据传输对象-DTO

DTO-在进程之间传送数据的对象，它还执行数据验证：

struct LoginDto: Dto {
    @Validated(.nonEmpty(message: "Please enter user name"))
    var username: String?

    @Validated(.nonEmpty(message: "Please enter password"))
    var password: String?
    
    var validatedProperties: [ValidatedProperty] {
        return [_username, _password]
    }
    
    init(username: String, password: String) {
        self.username = username
        self.password = password
    }
    
    init() { }
    
    static func validateUserName(_ username: String) -> Result<String, ValidationError> {
        LoginDto()._username.isValid(value: username)
    }
    
    static func validatePassword(_ password: String) -> Result<String, ValidationError> {
        LoginDto()._password.isValid(value: password)
    }
}

网关协议

通常，网关只是另一个抽象，它将隐藏实际的实现，类似于外观模式。它可以是数据存储（存储库模式），API网关等。例如数据库网关将具有满足应用程序需求的方法。但是，请勿尝试在此类网关后面隐藏复杂的业务规则。对数据库的所有查询都应相对简单一些，例如CRUD操作，当然也可以接受一些过滤。-来源

protocol RepoGatewayType {
    func getRepos(_ dto: GetPageDto) -> Observable<PagingInfo<Repo>>
}

注意：为简单起见，我们将网关协议和实现放在同一文件中。实际上，网关协议应该在域层，实现应该在数据层。

资料层

数据层包含网关实现和一个或多个数据存储。网关负责协调来自不同数据存储的数据。数据存储可以是远程或本地（例如，持久数据库）。数据层仅取决于域层。

参考资料

https://blog.devgenius.io/some-software-architecture-styles-fbb57f7716b9

https://www.nuomiphp.com/github/zh/5fdc441a99daa46c1242dceb.html

快看软件架构风格总结: 各种历史和现代软件架构风格的快速总结