利用残余理论构建更好的软件架构

软件架构之所以很难做，是因为它融合了编码、数学和业务系统几大领域。由于意外情况，架构往往会随着时间变得无足轻重，Barry O'Reilly 在哥本哈根的Goto会议上这样说。他提出了残余理论，建议对简单的架构施加压力，以揭示复杂业务系统中隐藏的“吸引子”。这使得设计能够更好地适应变化和不确定性。

软件架构之所以很难做，是因为它需要广泛的技能集，O'Reilly 说。我们必须掌握代码、数学和逻辑的世界，以及人类和业务系统的世界，并理解这两个世界如何相互关联和影响。

在大学里，他们只教我们技术。当我们开始设计系统时，我们意识到业务环境的复杂性不断给我们带来意外情况，使我们的架构变得无足轻重，O'Reilly 说。使像软件架构这样静态和僵化的东西在不断变化的流动世界中生存，并不是一件容易的任务，他补充说。

残余性假设对简单架构的随机压力模拟将产生比传统的需求工程、风险管理或对变化做出反应的方法更好的架构，O'Reilly 解释说：

这最初是一个好奇的观察，在过去的 10 年里，我不得不构建理论解释和实验来证明这确实是事实。有了这些知识，我们可以以不同的方式思考软件架构并构建新工具。

作为西方科学的学生，我们的第一个办法是将任何复杂系统简化为其多个组成部分，并详细研究这些部分。这是软件工程师的默认做法，O'Reilly 说。在复杂系统中，元素的数量和潜在的相互作用和状态使得这种以细节为导向的分析变得无法实现。前几代架构师试图将业务环境的复杂性简化为一系列逻辑、结构或开发过程。

复杂系统的关键之一是它们永远不会实现其元素组合所允许的所有可能状态。相反，元素之间的相互作用将系统限制在非常少量的潜在状态中，我们称之为“吸引子”，O'Reilly 说。因此，复杂的业务系统不是作为一系列交互元素及其关系来建模的，而是作为一系列吸引子来建模，他解释说：

当我们构建架构时，架构必须在这些吸引子中生存。因此，吸引子提供了一种更简单、更容易、更实用的方式来应对环境的复杂性。

问题是我们不知道吸引子是什么，但通过随机模拟压力，我们可以发现许多吸引子，O'Reilly 说。如果你回想一下你看到的架构失败的重大案例，你会发现它们大多数失败是因为错过了吸引子，他提到。

残余性理论是一个非常简单的过程。有时，人们因为证明残余性有效所需的理论工作非常繁重而感到沮丧，但应用它却很容易，O'Reilly 解释说：

我们从一个建议开始，一个解决功能问题的简单架构。从那里我们用潜在的环境变化来施加压力。这些压力允许我们发现吸引子，这里通常是通过与领域专家的对话。对于每个吸引子，我们识别残留物，即在这个吸引子中我们的架构留下了什么，然后我们改变简单的架构，使其更好地生存。

 

我们这样做很多次，最后将所有这些增强的残留物整合到一个连贯的架构中。然后我们可以测试它，以证明它比我们的简单架构更能承受未知形式的压力。

在充满不确定性的复杂业务环境中，残余性使得快速创建架构成为可能，而不是追逐哪些提出具体要求或回答业务本身未知的问题的利益相关者，O'Reilly 说。它将技术架构师从细节中拉出来，并教会他们如何在没有传统企业架构的线条和框框的情况下，有成效地参与业务环境，他总结说。

InfoQ 采访了 Barry·O'Reilly 关于残余性的问题。

InfoQ：我们如何证明我们创建的残余架构比天真架构有所改进？

Barry·O'Reilly：一个简单的测试是使用第二组压力测试来检查我们的残余架构是否比我们的简单架构更能承受更多的未知事件。你可以很容易地看到这与 ML 的训练/测试集之间的相似性。残余性理论最终表明，架构应该被训练，而不是被设计。

InfoQ：你从残余分析中看到了什么好处？

O'Reilly：高级架构师报告说，它为许多人已经想出的做法提供了理论依据，并为团队提供了一个共享的词汇来讨论架构。最终，它使架构更加明确、定义更清晰、更容易教授。结果是能让我们相信的架构和可追溯的决策。

 

它同样面临挑战。一小部分开发者发现，从我们训练有素的线性、逻辑、数学世界跳跃到横向、富有想象力的技术非常困难。面向对象编程（OOP）是一个与 OOP 一样庞大的主题，需要同样多的努力去学习。

原文链接：Producing a Better Software Architecture with Residuality Theory