?什么是軟件架構(gòu)？

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

如果我們從敏捷軟件開發(fā)的角度來看軟件架構(gòu)，我們很快就會得出這樣的結(jié)論：在實際實施之前，幾乎不可能在詳細(xì)級別上定義類和模塊，因為需求可能會隨著Sprint的進(jìn)行而快速變化，而應(yīng)用程序本身也會隨著時間的推移而不斷變化。

那么，在開始正式實現(xiàn)軟件系統(tǒng)之前，用來具象化我們將要開發(fā)的系統(tǒng)的軟件架構(gòu)到底是什么？

根據(jù)Ralph Johnson的說法，軟件架構(gòu)被定義為：“架構(gòu)是非常重要的東西，不管它是什么！”

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

一個軟件架構(gòu)基本上代表了一個軟件團(tuán)隊所做的決定。它不是關(guān)于記錄或畫圖，而是關(guān)于開發(fā)團(tuán)隊一起為軟件設(shè)計做出的決定。軟件開發(fā)者、設(shè)計者、產(chǎn)品經(jīng)理因此在具體的架構(gòu)決策上達(dá)成一致，如REST或GraphQL、Python或JavaScript、開發(fā)兩個服務(wù)或只寫一個服務(wù)。

這也使軟件架構(gòu)師的角色有了完全不同的意義。你不是在黑暗的柜子里用UML和BPMN設(shè)計一個軟件架構(gòu)，然后把圖交給軟件團(tuán)隊。這個角色的目的是指出軟件架構(gòu)的不同觀點，并與團(tuán)隊一起為軟件架構(gòu)做出決定，而不是替團(tuán)隊做出架構(gòu)設(shè)計。畢竟，團(tuán)隊最終會實施它。

那么，什么是最好的軟件架構(gòu)？

有幾種軟件架構(gòu)風(fēng)格，如微服務(wù)或基于空間的架構(gòu)。但顧名思義，它們只是可以用于決策的風(fēng)格。

這實際上很快就回答了什么是最好的軟件架構(gòu)的問題，從來沒有最好的軟件架構(gòu)這一說。一個團(tuán)隊齊心協(xié)力、盡己所能地為這個軟件考慮作出的決定，是為整個團(tuán)隊和軟件需求所能給出的最佳軟件架構(gòu)。這是因為所有的團(tuán)隊資源都被用來讓團(tuán)隊的每個個體都參與到?jīng)Q策過程中，以現(xiàn)有的人員開發(fā)出最好的架構(gòu)。

如果完全相同的需求提供給另一個團(tuán)隊，可能會做出完全不同的架構(gòu)策略。然而，這些策略又會是整個團(tuán)隊的最佳決定。這是全體軟件開發(fā)人員能夠?qū)崿F(xiàn)所要開發(fā)的軟件的唯一方法。

盡管如此，在我的職業(yè)生涯中，有一種架構(gòu)風(fēng)格是我所了解的，并且經(jīng)得起時間的考驗。最重要的是，我?guī)缀鯖]有再開發(fā)過不是這種架構(gòu)風(fēng)格的應(yīng)用程序。

我們談?wù)摰氖穷I(lǐng)域驅(qū)動的六邊形架構(gòu)，或者也叫領(lǐng)域驅(qū)動的六邊形。這種架構(gòu)風(fēng)格是Eric Evans的領(lǐng)域驅(qū)動設(shè)計、Robert C. Martin的Clean Architecture和Clean Coder以及Alistair Cockburn的六邊形架構(gòu)（也叫Ports and Adapters）的混合體。在這里，來自知名程序員的不同概念被結(jié)合起來，以實現(xiàn)清晰的規(guī)則和清晰的應(yīng)用結(jié)構(gòu)，但仍將個別架構(gòu)的決定，如REST或GraphQL，Python或NodeJS，留給團(tuán)隊。

這里有一張領(lǐng)域驅(qū)動六邊形的圖片，它很好地說明了如何定義清晰的規(guī)則，但又為架構(gòu)決策留下了足夠的空間。

　　領(lǐng)域驅(qū)動六邊形

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

放到架構(gòu)設(shè)計的案例中：從長遠(yuǎn)來看，整個團(tuán)隊對架構(gòu)的“編排”比起團(tuán)隊中部分人對架構(gòu)進(jìn)行“協(xié)調(diào)”會具有更好的表現(xiàn)：這些人確實能夠快速推動架構(gòu)的決策和演進(jìn)，但其余的團(tuán)隊成員卻被忽略了。

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