到底什么是软件架构？ _软件架构

很多人都在谈论那件事，但实际上只有少数人在谈论有时会有人提到这个词。在最多样化的环境中。这个词曾被用来表达许多不同的事物，当一个单词可以表达任何含义时，它最终就意味着什么。在本文中，我经过大量研究后，以迄今为止最精确的方式解释了我对软件体系结构的看法。

文章插图
> A library's architecture doesn't define how the books are going to be organized

作为软件制作者，我们将根据目前对编程以及应用程序业务领域的了解，尽力而为地编写代码。
随着时间的流逝，我们不仅学到了编程技术，而且学到了业务领域的特殊性和特征，而且学到了越来越多的东西。
趋势在变化，新的编程技术不断涌现，其中一些在市场上越来越受关注。随着更多功能添加到软件中，业务领域也不断发展和变化。
因此，我们编写的代码似乎正在慢慢衰减，因为我们在编写时没有掌握新知识。每次查看较旧的代码时，我们都会更加确信它不再反映出应该解决的最佳模型。

文章插图
> Code decaying over time

这是正常的。它从项目开始就发生，并将一直持续到结束。软件之所以软是因为它被更改了。重构。实验过已调整。已更正。递增。
但是更改此代码并非易事，因为在大多数情况下，系统很复杂。变更的影响并不总是很明显。我们害怕破坏某些东西而感到震惊。这就是我们编写自动化测试的原因。能够无所畏惧地更改软件。为了能够重写，调整，试验，修复。

文章插图
> Automated tests to measure the impact of change

不仅要知道软件是否可以运行。如果我们永远都不会改变该系统，那么经过良好的手动测试将非常擅长于确保一个版本能够正常工作。也许比自动测试更好，因为手动测试是强制性的端到端，并且还可以捕获UX和业务领域中无法预料的问题。
事实证明，编写自动化测试不足以使我们的软件易于更改。如果代码与实现细节（如UI，数据库以及与其他系统的通信）过于耦合，则代码中的任何更改都将受到这些外部因素强加给我们代码的固有建模的约束。
对业务规则建模方式的任何更改都将在多个自动化测试和实施详细信息中进行更改。要改善业务规则中变量的名称，就是要使其在数据库，屏幕或其他位置也进行更改。较大的变化，结构性变化会放松我们的脊柱。

文章插图
> When one change causes others

这就是创建架构的原因。在对系统建模时，架构并不是要遵循的秘诀。这不是术语。这不是将业务规则组织到类或方法中的方法。架构不是DDD [1] 。
架构是将我们的代码与外部因素隔离开来的方法，因此我们可以自由地以我们目前认为最好的方式对问题的解决方案进行建模和重新建模。然后重新进行建模。然后再次。
当今最著名的架构之一是清洁建筑：

文章插图

在本文中，鲍勃叔叔似乎确实提供了秘诀，术语以及将业务规则组织到类和方法中的方法。但是，如果仔细阅读，就会发现所有架构的目标都是实现所谓的独立性，即所谓的自由。
自由学习和改造系统而不会破坏一切。自由清理代码。
这就是为什么有用例（交互器）的原因。它们代表用户可以在系统中执行的操作。它们是UI和应用程序之间的通信桥梁。这就是为什么有Presenters的原因，当涉及到一些额外的处理来呈现信息时，Presenter会从应用程序返回到UI 。它们是外壳的一部分，它们可以不同地命名，也可以具有其他形式，只要它们能够发挥其隔离作用即可。
从那里开始，不应强加严格的规则。这才是重点。不受规定的约束。我们已经编写了所有测试，所有用例和演示者都存在，因此我们拥有更大的自由度来定义实体的状态以及它们的行为方式。

文章插图
> Once the library's architecture is ready, we can organize the books as we please

因此，我们自己可以定义它们是否应该是函数，类，应该具有多少种方法。如果它们将在网关（存储库）中实例化，则它们将在构造函数或方法中接收数据。以及任何其他建模方式。