想想回到过去的美好时光，根本没有所谓架构，那些日子是多么幸福啊，只有了解 GoF 模式，你就能称自己为架构师。 然而，计算机变得更加强大，用户的需求增加，导致应用程序的复杂性增加。 开发人员解决的第一件事是将UI 与业务逻辑分离。

根据 UI 框架的不同，诞生了不同的类似 MVC 的模式：

​ 这在一段时间内有所帮助，但效果并不那么明显。 如果你和我一样来自 C# 社区，你可能会错误地认为那些图中名为Model的黄色框只是 DTO。 这一切都是因为微软。 他们让我们对他们的 ASP MVC 框架感到困惑。 事实上，这里的Model代表领域模型，也称为业务逻辑，这在任何应用程序中都相当关键。 你能打赌，上面这三个组件中哪一个造成的问题最多？虽然视图只是简单的图像和按钮，但控制器充当中间人，所有复杂性都集中在模型中。

那是一个 GoF 模式根本不够用的时期。因此必须出现新的想法。我们如何处理复杂性？

分而治之。

我们已经使用 MVC 做到了，所以让我们再做一次。

N层架构

这种体系结构将应用程序组织成水平层，每个层负责特定的任务。

• - 表现层
• - 业务逻辑
• - 数据存取

六边形结构

也称为端口和适配器，六边形架构将核心应用程序与外部依赖项隔离。 核心定义端口/接口，而适配器是实现。 这种架构通过将应用程序与框架和技术分离，提高了灵活性和可测试性。

洋葱架构

基于六边形架构的原则，洋葱架构在核心/域和基础设施之间建立了明确的分离。 层围绕着核心，内层表示抽象的业务关注点，外层处理技术细节和框架。

Clean架构

由Uncle Bob提出的clean Architecture强调关注点的分离以及业务规则与外部框架的独立性。 层之间的清晰边界确保了可伸缩性、可维护性以及与项目需求的一致性。

这些体系结构提供了不同的方法来设计软件系统，每一种都有其优点和缺点。 但最终，体系结构的选择取决于项目的特定需求！

结论

在本文中，我们讨论了 N 层、DDD、Hexagon、Onion 和 Clean 架构。这些并不是唯一存在的架构。然而，所描述的是最著名的。您可能还听说过 BCE、DCI 等。 尽管细节上存在细微差别，但所有架构几乎都是相同的。它们都服务于同一个目的——分担责任。他们都是通过将代码拆分到不同的层来实现的。全部区别在于定义了哪些组件以及这些层之间存在哪些依赖关系。

详细点击这里