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

大泥球(Big Ball of Mud)

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

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

管道架构

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

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

基于服务的架构

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

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

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

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

Clean Architecture

• 域层：实体+用例+ 关协议

• 数据层： 关实现+ API（ 络）+数据库

• 表示层：视图模型+视图+导航器+场景用例

实体

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

实体是简单的数据结构：

用例

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

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

数据传输对象-DTO

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

关协议

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

资料层

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

参考资料

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

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

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览93644 人正在系统学习中