?什么是軟件架構？

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

如果我們從敏捷軟件開發的角度來看軟件架構，我們很快就會得出這樣的結論：在實際實施之前，幾乎不可能在詳細級別上定義類和模塊，因為需求可能會隨著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，留給團隊。

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

　　領域驅動六邊形

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

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

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