說明性架構

我們對軟體系統的理解之所以會增長，其中一個問題在於我們看到的範例不夠多。在許多專業領域中，人們會透過觀察既有成果來學習。範例可作為靈感、提供好點子，並警告困難之處。很長一段時間以來，要透過這種方式學習軟體都難得多。

我一直很喜歡觀察系統如何組成。我希望有更多時間這麼做，並分享一些我看到比較有趣的架構。我將這些架構視為說明性架構，因為它們就像展示屋或花園。雖然它們可能不完全符合你的目的，但它們包含你可能想複製的某些面向。

如需查看此類文章的清單，請參閱 說明性架構標籤。

我通常會避免使用「架構」這個詞，因為它是一個非常模糊的術語。在這種情況下，我將遵循 我偏好的架構定義 - 「重要的東西（無論是什麼）」 - 來自 Ralph Johnson。這表示我將根據我的判斷，以及參與開發團隊的判斷，來討論我認為系統設計中有趣的內容。

我使用「說明性」這個術語，強調這些架構是提供有趣點子的來源，它們並非旨在成為某種「最佳實務」。首先，我非常謹慎地看待被設定為某種標準的架構，因為在建構具體系統時，有許多變數需要留意。例如，許多人強調可擴充架構的重要性（他們通常指的是處理大量負載的能力）。然而，許多有用的系統都是內部系統，從未有過高負載，因此應該設計為支援不同的驅動程式組。

強調不成功的因素通常很有用。我們不只是透過觀察運作良好的事物來學習，不成功的案例通常可以作為避免誘人道路的良好指南。而且，某些架構功能通常會受到某些團隊成員的喜愛，但卻受到其他成員的厭惡。透過了解驅動喜愛和厭惡的因素，你可以了解它是否符合你的架構美學。

我不會很頻繁地撰寫說明性架構文章，因為撰寫這些文章需要花費大量時間和精力。要深入了解一個系統，才能了解它的運作方式和有趣的點在哪裡，需要花費一段時間。開發團隊也需要花費時間和精力來解釋事情，並確認我沒有誤解任何內容。

我預期我將描述的大部分架構都來自 Thoughtworks 專案，因為它們對我來說較容易取得。不過這並非絕對的規則，如果在有時間處理時，看到非 TW 專案吸引我的目光，我也很樂意討論 [1]。

我撰寫的任何說明性架構都將基於至少一個真實系統。我比較喜歡已經生產一年左右的系統，因為許多在開發階段看起來不錯的東西，在實際上線一段時間後，結果會有所不同。不過這只是一個偏好，而非絕對的規則。

在描述架構時，我會為架構取一個名稱作為參考，但通常這個名稱是我為我的說明所取的，因為系統名稱通常與客戶的環境息息相關。同樣地，我使用與我在這裡撰寫的其他內容一致的詞彙來描述系統，這些詞彙可能不是開發團隊實際使用的術語。