重新理解架構

“系統設計”可以用來描述我在系統中定義的某些規則或設計的明確的模組？還是說，它就是我定義的具體的類和函式？

如果我們從敏捷軟體開發的角度來看軟體架構，我們很快就會得出這樣的結論：在實際實施之前，幾乎不可能在詳細級別上定義類和模組，因為需求可能會隨著Sprint的進行而快速變化，而應用程式本身也會隨著時間的推移而不斷變化。

那麼，在開始正式實現軟體系統之前，用來具象化我們將要開發的系統的軟體架構到底是什麼？

根據Ralph Johnson的說法，軟體架構被定義為：“架構是非常重要的東西，不管它是什麼！”

這個定義一開始肯定會讓人清醒下來，然而它卻蘊含著許多真理。

一個軟體架構基本上代表了一個軟體團隊所做的決定。它不是關於記錄或畫圖，而是關於開發團隊一起為軟體設計做出的決定。軟體開發者、設計者、產品經理因此在具體的架構決策上達成一致，如REST或GraphQL、Python或JavaScript、開發兩個服務或只寫一個服務。

這也使軟體架構師的角色有了完全不同的意義。你不是在黑暗的櫃子裡用UML和BPMN設計一個軟體架構，然後把圖交給軟體團隊。這個角色的目的是指出軟體架構的不同觀點，並與團隊一起為軟體架構做出決定，而不是替團隊做出架構設計。畢竟，團隊最終會實施它。

有幾種軟體架構風格，如微服務或基於空間的架構。但顧名思義，它們只是可以用於決策的風格。

這實際上很快就回答了什麼是最好的軟體架構的問題，從來沒有最好的軟體架構這一說。一個團隊齊心協力、盡己所能地為這個軟體考慮作出的決定，是為整個團隊和軟體需求所能給出的最佳軟體架構。這是因為所有的團隊資源都被用來讓團隊的每個個體都參與到決策過程中，以現有的人員開發出最好的架構。

如果完全相同的需求提供給另一個團隊，可能會做出完全不同的架構策略。然而，這些策略又會是整個團隊的最佳決定。這是全體軟體開發人員能夠實現所要開發的軟體的唯一方法。

儘管如此，在我的職業生涯中，有一種架構風格是我所瞭解的，並且經得起時間的考驗。最重要的是，我幾乎沒有再開發過不是這種架構風格的應用程式。

我們談論的是領域驅動的六邊形架構，或者也叫領域驅動的六邊形。這種架構風格是Eric Evans的領域驅動設計、Robert C. Martin的Clean Architecture和Clean Coder以及Alistair Cockburn的六邊形架構（也叫Ports and Adapters）的混合體。在這裡，來自知名程式設計師的不同概念被結合起來，以實現清晰的規則和清晰的應用結構，但仍將個別架構的決定，如REST或GraphQL，Python或NodeJS，留給團隊。

這裡有一張領域驅動六邊形的圖片，它很好地說明了如何定義清晰的規則，但又為架構決策留下了足夠的空間。

這可以用道路交通的一個例子來作比較。讓道路上的每個人都遵守同樣的規則，比讓少數人遵守類似的規則，然後讓其他人都跟著這少部分人來做要好。在道路交通中，人們做出什麼樣的決定取決於每個個體，但車流的方向卻是明確規定的。那麼，其實我們只要遵守最終得到的規則就好了。

放到架構設計的案例中：從長遠來看，整個團隊對架構的“編排”比起團隊中部分人對架構進行“協調”會具有更好的表現：這些人確實能夠快速推動架構的決策和演進，但其餘的團隊成員卻被忽略了。

因此，從長遠來看，協調得到的軟體架構在長期的波動中無法承受簡單的變更和較短的開發實施時間，而“編排”的軟體架構即使最初會因為團隊成員之前的高同步成本而變得遲緩，但持久地卻能產生高效的結果，抵禦波動。總的來說，相互之間的開發比相互之間的競爭要有趣得多。