阐释式架构

我们对软件系统理解不断加深的一个问题是，我们没有看到足够的例子。在许多专业领域，人们通过观察已经完成的工作来学习。例子可以作为灵感来源、良好想法的来源以及对困难的警示。长期以来，以这种方式学习软件要困难得多。

我一直很喜欢看看系统是如何组合在一起的。我希望有更多时间来做这件事，也希望分享一些我看到的更有趣的架构。我认为这些架构是阐释式架构，因为它们就像样板房或花园。虽然它们可能不是你自己的目的所需要的，但它们包含你可能想要复制的方面。

有关此类文章的列表，请参阅阐释式架构标签。

我通常会避免使用“A”字（架构），因为它是一个非常模糊的术语。在这种情况下，我将遵循我对架构的偏好定义 - “重要的东西（无论是什么）” - 来自拉尔夫·约翰逊。这意味着我将根据我的判断以及参与其开发的团队的判断，谈论我认为系统设计中有趣的地方。

我使用“阐释式”一词来强调这些架构是有趣想法的来源，它们并非旨在成为某种“最佳实践”。首先，我非常警惕那些被设置为某种标准的架构，因为在构建具体系统时，有太多变量需要关注。例如，许多人强调可扩展架构的重要性（他们通常指的是处理大量负载的能力）。然而，许多有用的系统是内部系统，从未有过高负载，因此应该设计为支持不同的驱动程序集。

突出显示没有取得成功的因素通常很有用。我们不仅通过观察运作良好的事物来学习，没有取得成功的因素通常可以很好地指导我们避免一条诱人的道路。而且，某些架构特征通常会受到一些团队成员的喜爱，而受到其他团队成员的厌恶。通过了解是什么驱动了这种喜爱和厌恶，你可以了解它是否适合你的架构美学。

我不会经常发布阐释式架构帖子，因为它们确实需要花费大量时间和精力来撰写。需要一段时间才能充分了解一个系统，才能了解它的工作原理以及有趣的地方。它还需要开发团队花费时间和精力来解释事物并验证我没有把任何东西弄错了。

我预计我将描述的大多数架构将来自 Thoughtworks 项目，因为它们更容易让我接触到。然而，这不是一个绝对的规则，如果我看到一些让我感兴趣的东西，并且我有时间去处理它，我将很乐意谈论非 TW 项目[1]。

我撰写的任何阐释式架构都将基于至少一个真实系统。我更喜欢已经投入生产一年左右的东西，因为许多在开发中看起来不错的东西，一旦你上线一段时间就会变得不同。但这是一种偏好，而不是一个绝对的规则。

在描述架构时，我会给架构起一个名字作为参考，但通常这个名字是我为我的描述而编造的，因为系统名称通常与客户的上下文联系太紧密。同样，我使用与我在这里写的内容一致的词汇来描述系统，这可能不是开发团队实际使用的术语。