“你對架構這個詞怎麼了解？”
emm …..
實際上，軟體架構分成 2 派。
組成派
組成派的定義非常簡潔。
定義：軟體系統的架構将系統描述為計算元件及元件之間的互動。
剖析定義：
a. 該架構關注架構實踐中的客體——軟體，以軟體本身為描述對象。
b. 分析了軟體的組成，即軟體由承擔不同任務的元件組成，這些元件通過相關互動，完成更高層次的計算。
決策派
決策派的定義相對于組成派的定義，要繁雜很多。但核心思想非常明确：軟體架構是在一些重要方面所做出的決策的集合。
定義（軟體架構包含了關于以下問題的重要決策）：
軟體系統的組織
選擇成為系統的結構元素和他們之間的接口，以及當這些元素互相協作時所展現的行為。
如何組合這些元素，使他們逐漸合并成更大的子系統。
用于指導這個系統的架構風格：這些元素以及它們的接口、協作群組合。
軟體架構并不僅僅注重軟體本身的結構和行為，還注重其他特性：使用、功能性、性能、彈性、重用、可了解性、經濟和技術的限制及權衡，以及美學等。
架構設計是分與合的藝術。
架構 = 元件 + 互動。
我們舉例 mvc 架構：
v 建立 c，c 根據使用者互動調用 m 的相關服務，而 m 将自身的改變通知 v，v 通過互動讀取 m 的資訊以更新自身。
架構屬于設計，但設計不一定屬于架構。架構設計的決策，将對整體品質、并行開發、适應變化等方面有着重大影響，例如：
子產品如何劃分
每個子產品的職責如何
每個子產品的接口如何定義
子產品間采用何種互動機制
開發技術如何選型
如何滿足限制和品質屬性的需求
如何适應可能發生的變化
這裡假設我們設計一個 c/s 系統，會有一個決策樹：
決定采用 c/s 架構，包含 client 和 server
決定将 server 分成 3 層
決定将 server 的引擎層劃分成 n 個子產品
決定 …..
可以看出，決策，就是一步步遞歸，将大任務，通過一個個合理的決策，劃分成一個個小任務。是不是類似 fork join 呢？
另外，從上面也可以看出，不是隻有大系統才有架構，小的子產品，小的系統也有架構。是以，在平時編寫代碼時，即使自己負責的系統很小，也要關心，設計好他的架構。
無論是組成派，還是決策派，在架構設計中，我們都會涉及，隻是站的角度不同罷了，前者站在軟體的角度，後者站在決策人的角度。
例如：
當我們決定對子產品如何進行劃分的時候，這個時候，是決策派。
當我們設計子產品邊界的時候，是組成派。
當我們對子產品之間的互動接口進行設計的時候，就是組成派。
當我們考慮易用性，代碼美學，靈活性的時候，是決策派。
……
最後，管他什麼派，隻是角度不同罷了，好的架構，我認為是這樣的：子產品邊界清晰，依賴合理，彈性靈活，性能優越，易于了解。
軟體架構設計——溫昱