本文來自於：Software Architecture in Practice 3rd Edition--Addison-Wesley
Len Bass
Paul Clements
Rick Kazman
1.4 What Makes a “Good” architecture?
這幾天在做一個軟件架構的短視頻，系統的看了一些軟件架構的知識。和對任何概念的認識一樣，學習軟件架構也同樣需要明確定義和評判標準。所以，我們得搞明白兩件事情
- 軟件架構的定義，即軟件架構是什麼
- 軟件架構的評判標準，即什麼纔是好的架構
今天我們先不看定義，只看“軟件架構的評判標準，即什麼纔是好的架構”。網上搜一下“軟件架構”，你會得到無數的定義和評判標準。不過，我們今天不關注“羣衆的呼聲”，而是看一下業界大佬的觀點，即：Software Architecture in Practice 3rd Edition中的觀點。
正文開始
什麼纔是好的架構
沒有內在就好或壞的架構。架構或多或少都滿足了某種目的。三層結構的SOA架構可能是大型企業基於Web的B2B系統的首選，但，這種架構對於航空應用來說卻是完全錯誤的。精心設計地以實現高可修改性(high modifability)爲目的的架構對於用完就扔的原型應用來說就毫無意義（反之亦然！）。本書傳達的信息之一就是，架構實際上是可以被評估的(evaluated)--這也是關注架構所帶來的巨大收益中的一個，但，只有在有明確目標的上下文中才能被評估。
儘管如此，在設計大多數的架構時，依然應該遵循一些經驗法則。不滿足其中的某一個法則，並不意味着該架構一定具有着致命的缺陷，但至少它應該作爲需要進行研究的警告信號。
我們把我們的觀察結果分爲兩個類別：過程建議(process recommendations)和產品（或結構）建議(production/structural recommendations)。
我們的過程建議(process recommendations)如下：
- 架構設計應該由一位架構師來完成，或者由一小組架構師來完成，這一小組架構師由一個被認可的technical leader所領導。這使得架構具有概念完整性和技術一致性。該建議既適用於敏捷項目和開源項目，也適用於“傳統”項目。架構師與開發團隊之間應該保持緊密聯繫，以避免不切實際的象牙塔(ivory tower)設計。
- 架構師（或架構團隊）應該始終把架構建立在 劃分了優先級的 定義明確的 質量屬性要求(quality attribute requirements)之上，這會時時提醒架構師需要權衡。功能不那麼重要。
- 架構應該使用視圖的方式記錄。視圖應該解決最重要的利益相關者(stakeholder)的關注點，以支持項目的時間表。這意味着一開始可能需要最少的文檔，後期再補充詳細內容。關注點通常與系統的構建、分析、維護，以及對新stakeholder進行該系統的培訓 有關。
- 應該評估架構交付系統最重要的質量屬性(quality attributes)的能力。這應該發生在生命週期的早期，這時得到的收益最大，在適當情況下需要重複評估，以確保對架構（或架構的預期環境）的改變不會導致設計過時。
- 架構應該能夠被增量實現(incremental implementation)，以避免必須一次集成所有內容（這幾乎總是行不通的）以及儘早發現問題。 實現該目的的一種方法是創建一個“skeletal system”，在“skeletal system”中實現通信鏈路可運行(the communication paths are exercised)，但起初只有最少的功能。該“skeletal system”可被用以逐步“增長”系統，在必要時進行重構。
我們產品（或結構）建議(production/structural recommendations)如下：
- 架構應具有定義明確的模塊(module)，模塊的功能職責是根據“信息隱藏和關注點分離(information hiding and separation of concern)的原則”來分配的。信息隱藏模塊應該封裝可能發生變化的部分，從而使軟件免受這些變化的影響。每個模塊應具有定義明確的接口，對於使用該模塊的其他軟件的來說，這些接口封裝或“隱藏”了這些可變部分。這些接口應允許它們各自的開發團隊在很大程度上獨立於彼此工作。
- 除非您的需求是前所未有的（存在這種可能性，但，不太可能發生），否則您的質量屬性(quality attribute)應使用 針對每個質量屬性的 well-known的 架構模式和策略(tactic)來實現（在第13章進行了介紹）。
- 架構永遠不應依賴於某個特定版本的商業產品或工具。如果必須的話，應該對架構進行結構設計，使得更改依賴到某個其他版本時能直接且代價較小
- 生產數據的模塊和消費數據的模塊應該分開。這樣能增加可修改性(modifability)，因爲改變經常被限制在生產方或消費方。如果添加了新數據，則生產方和消費方都必須進行更改，但是這種分離允許分階段（增量）升級。
- 不要期望模塊(module)和組件(component)之間一一對應。例如，在併發系統中，可能有多個組件實例並行運行，其中每個組件都是從同一模塊構建而來。對於具有多個併發線程的系統，每個線程可以使用來自多個組件的服務，每個組件都是從不同的模塊構建而來。
- 每個進程都應該是可寫的，以便可以修改分配給其的處理器，甚至在運行時修改分配給其的處理器
- 架構應具有少量的組件交互方式。 也就是說，系統應該始終以相同的方式執行相同的事情。 這樣有助於增加可理解性，減少開發時間，增加可靠性，並增強可修改性。
- 架構應包含一組特定（且較小）的資源爭用區域，並明確規定和維護其解決方案。例如，如果網絡利用率是一個值得關注的點，則架構師應爲每個開發團隊制定（並執行）可以使得網絡流量最小化的方案指南； 如果性能是關注點，那麼架構師應該爲主要線程制定（並執行）時間預算方案指南
完