架构就是上下文 - Eltjo

架构就是上下文 - Eltjo

Eltjo Poort 是 CGI 荷兰的架构实践负责人，在软件行业拥有超过 30 年的经验。

Eltjo 首先解释了架构上下文和业务驱动程序的重要性，它们可以帮助架构师理解不同的权衡和选项，以便做出正确的架构决策。

Eltjo 分享了架构师的主要职责，以及架构师应如何通过了解架构文档的不同目标来避免编写又大又长的架构文档。

架构是上下文

• 当你学习软件设计时，你会学到很多好的设计原则。您知道，根据思想流派的类型，您要么学习如何将新系统的职责分解为几个组件，要么学习如何查看共同职责并设计类和对象以及它们之间的关系。并且有很多好的设计原则，比如信息隐藏，或低耦合和高内聚。
• 但是，对我而言，如果您不只是关注这些通用的、良好的设计原则，而是真正关注应用它们的业务环境上下文，它就会成为架构。
• 我认为你实际上需要注意的是在这个特定上下文的系统中，在这个具有这些特定业务驱动的环境上下文中。你做出的每一个设计选择都有替代方案。只有了解上下文驱动的这个因素，才能在这些备选方案之间做出正确的权衡。这些可以是商业驱动。这可能是时间压力。他们可以是技术驱动力。
• 作为一名架构师，你不应该躲在你的象牙塔里，只做伟大的设计，因为你做不到。如果您不与业务人员或业务利益相关者以及可以告诉您在这种特定情况下什么是重要驱动因素的技术利益相关者交谈，您就无法做出正确的权衡。

了解业务驱动力

一个好的架构师需要一直问业务 "为什么？"。仅仅知道业务需要什么，还不足以做出正确的权衡。你需要知道他们需要它的原因，因为这才是真正的架构驱动力所在。

除非我们知道原因，否则我们无法帮助他们做出这个决定。是的，他们当然会说我们想要一切。但他们只是说他们想要所有的东西，因为他们没有意识到其中的利弊。他们做出的每个选择都有缺点，我认为我们的工作是向他们指出这些缺点。具体来说，就是用他们的语言指出这些缺点和这些权衡。

如果我们说你对这种特定的方式有偏好，但它会导致一个更复杂的系统，你就无法说服他们。他们并不担心系统会更复杂。他们说，那是你们的工作。你是建筑师，对吗？你是技术人员。所以你要处理复杂的问题。

你需要把这种复杂性转化为它对业务的意义。

一个更复杂的系统意味着它可能需要更多的人去控制复杂性，所以它将会更昂贵。

但是，对于商业人士来说，也许更有趣的是它实际上增加了错误的风险。因为在一个更复杂的系统中，我们不可能总是监督一个特定变化的全部影响。一个看似简单的变化实际上可能会影响到很多其他组件，这意味着更多的工作。因此，再一次，更昂贵。

但是，也有更多的风险，因为有额外的依赖关系，我们可能会错过一个依赖关系，或者一个接口可能会发生我们不知道的变化，等等。

如果我们把这些权衡转化为商业术语，那么我们就可以帮助他们参与决策，做出正确的架构选择，正确的设计选择，而不是仅仅因为他们想要所有的东西却不了解所有的东西而感到恼火。

不正确的架构决定

谈到糟糕的决定或过去遗留的决定，实际上不可避免地要做出一些事后可能被证明不是最优的决定。

[Philippe Kruchten]说，软件架构师的生活是一个漫长的、有时是痛苦的、部分在黑暗中做出的次优决定的连续过程，这让人感到沮丧。为什么架构师时常会做出事后证明是错误的决定呢？这与作为一个架构师必须做出的决定的顺序有关。

基本上，它归结为你必须在你拥有最少事实知识的时候做出最重要的决定。当然，你会尽一切努力来避免这种情况。你试图保持你的选择开放。你试图推迟你的决定，直到实际上进一步推迟会破坏事情，或者会使人们不能再工作的时间点。当然，你尝试一切办法来推迟决定，直到你有更多的知识。

然而，你必须先做出最重要或最有影响的决定。因为你所做的每一个决定都会制约你以后在同一设计空间中必须做出的所有其他决定。所以，你的架构决定，会减少你的设计空间。它们减少了你以后的选择。

而你不希望的是，一个低影响的决定和不重要的决定制约了你的选择，使你以后不得不做出更多的高影响的决定。这实际上是以错误的方式进行的。所以你必须先做最重要的决定，因为你想让高影响的决定制约低影响的决定，而不是反过来。

这意味着，无论你做什么来保持你的选择，到最后，你最终做出的决定，实际上如果你在两个月后知道的话，你会以不同的方式来做。所以这就是为什么不可避免地会陷入那种情况。你有时会做出一个错误的决定。你必须接受这一点。

了解架构的权衡

这需要采取一些步骤。当然，首先你需要了解这些需求，以及它们是如何相互冲突的。有些需求永远不会冲突，比如功能需求，我们希望系统做什么。要么他们必须做这个，要么他们必须做那个。它们不会发生冲突。

但是，冲突实际上出现在其他需求中。那些不仅仅是关于普通功能的需求，我们通常称之为非功能需求，但实际上更好的名称是质量属性需求。这些是像性能或可修改性或可用性等的东西。这就是架构权衡的地方。

还有一类非功能需求，或者有些人称之为约束条件，这与按时交付或与特定人群一起创建软件有关。

而这些都是真正推动架构决策的东西。仅仅是单纯的功能，功能需求驱动架构的情况非常罕见。所以，你必须了解这一点，你必须了解这些非功能驱动因素是什么。

然后，当然，你也必须知道你有哪些不同的选择。如果你不得不做出决定，去选择你认为只有一种选择的东西，或者只有一种选择，那就不是决定。决定是如果你有几个选择。因此，为了做出正确的决定，你还需要确保你知道你有哪些选择。 

更多点击标题