Software Architecture軟體架構是啥
隨著軟體行業的發展，軟體的規模越來越大，“Software Architecture軟體架構”這個名詞開始頻繁出現。“軟體架構”究竟指的是什麼？
廣義的“軟體架構”針對整個軟體系統，當然包括“軟體系統”的全部內容，同時包括網路、計算機，外部裝置等物理節點，以及開發者，維護者和客戶等人員。
狹義的“軟體架構”指的是軟體開發過程中，軟體頂層架構的設計。
本文討論的是狹義的軟體架構，主要包括三方面的內容：
- 架構模式：頂層模型的設計方法
- 設計模式：框架類結構的設計方法
- 架構設計目標：非功能性的約束
Software Architecture軟體架構憑啥
領域驅動設計(Domain Driven Design)
Eric Evans在《領域驅動設計－軟體核心複雜性應對之道》這本書中提出了傳統的DDD四層架構模式。
六邊形架構（Haxagonal Architecture）
六邊形架構是Alistair Cockburn在2005年提出的，解決了傳統的分層架構所帶來的問題。Vaughn Vernon 在《實現領域驅動設計》一書中，作者將六邊形架構應用到領域驅動設計的實現。將傳統的分層架構變成了內部和外部，內部實現領域模型，外部實現介面卡。
洋蔥架構（Onion Architecture）
Jeffrey Palermo在2008年提出了洋蔥架構。它是從六邊形架構發展而來，將六邊形改為圓環，層層依賴。
乾淨架構（Clean Architecture）
Robert C. Martin在2012年提出了乾淨架構（Clean Architecture），這是六邊形架構的一個變體。
DCI架構
DCI代表Data, Context, Interaction。ames O. Coplien和Trygve Reenskaug在2009年發表了一篇論文《DCI架構：物件導向程式設計的新構想》
重點是關注資料的不同場景的互動行為， 核心思想是將物件導向系統的資料模型和動態的行為模型區分開來，用不同的物件複用同一段互動行為。
Software Architecture軟體架構有啥
架構模式很難被具體化、框架化，因為它們太過抽象，只是若干設計原則，這樣的框架即使被設計出來，也難以流行起來。
相對於抽象的架構模式，框架類設計模式還是很流行的。最流行的當然是MVC框架模式。
MVC框架模式
MVC即模型(model)、檢視(view)、控制器(controller)設計模式可謂是無人不知不人不曉。它的缺點是比較重，各部分沒有解耦。
MVP框架模式
Model-View-Presenter設計模式是在MVC基礎上發展而來，將模型與檢視完全分離，可以修改檢視而不影響模型。
MVVM框架模式
Model-View-ViewModel設計模式是MVP的進一步改進，使用雙向繫結將View與ViewModel的資料傳輸自動化。
VIPER框架模式
VIPER模式最初是在2013年由Jeff Gilbert 和 Conrad Stoll 提出，隨後在《Architecting iOS Apps with VIPER》文中做了詳細的介紹。
由View+Interactor+Presenter+Entity+Routing組成，是Clean Architecture的一種實現模式。
Software Architecture軟體架構幹啥
軟體架構設計最大的困難與問題在於，架構模式過於抽象，很難有具體的框架支撐，很難重用程式碼；設計模式可以有具體的框架類支援，不進行架構設計，直接使用框架是可以的，但是很難支撐複雜系統的高層架構。
所以，對於軟體架構設計最有意義的事情，就是把抽象和具體連線起來，既是抽象的模式，同時又是具體的可重用框架。
結合具體的專案過程，我設計了一個模式，同時也實現了一個框架。
Bricks Architecture（磚塊架構）
這個模式，命名為Bricks Architecture（磚塊架構）。
這個框架，命名為Bricks（離別鉤），出自《七種武器》：“你用離別鉤，只不過為了要相聚”。
Bricks是一個完全模組化的模式，主要有六種模組：Builder+Router+Interactor+Context+bricK+Scenario。
與乾淨架構（Clean Architecture）的關係
Bricks Architecture既是Clean Architecture的一種變體，同時也是Clean Architecture的一種實現模式。
Brick對應於Entities
Context對應於UseCases
Adapter對應於Adapters
與DCI架構的關係
Bricks Architecture既是DCI的一種變體，同時也是DCI的一種實現模式。
Brick對應於Data
Context對應於Context
Adapter+Interactor對應於Interaction
與MV*架構的關係
Builder可以實現為Generator，生成MVP架構的程式碼，如果使用雙向繫結如VUE，那麼將生成MVVM架構的程式碼
Builder也可以實現為Controler，載入手寫程式碼，可以視為MVC架構的程式碼。
與VIPER架構的關係
Model是由Builder根據Brick（Entity）生成
View是由Builder根據Context + Scenario生成
Presenter是由Builder據Context + Scenario+ Brick生成
那麼Bricks模式，在生成後變成VIPER，在程式碼生成後，實際程式碼是基於VIPER模式的。
（Builder+Context+Scenario）+ Interactor + bricK + Router
VIEW + Interactor + Presenter + Entity + Router
架構模式的動態選擇
程式碼生成，在成熟平臺如Web，可以完全應用，Bricks框架可以構建LowCode低程式碼平臺。生成的程式碼可以應用MVC，MVP，MVVM模式。
在程式碼生成不成熟的平臺，如手機平臺，可以部分應用或不使用，Bricks框架可以應用VIPER，Clean Architecture等複雜的模式。
動態選擇架構模式可以避免過度設計。
與軟體架構設計目標的符合度
由於Bricks是完全模組化的模式，在可定製化等方面有著天然的優勢。
- 可定製化（CuSTomizable）
- 可伸縮性（SCAlable）
- 可維護性（MAIntainable）
- 可擴充套件性（Extensible）
在安全性、可靠性方面，雖然整體強度是降價的，但是模組本身能夠被複用，被測試，模組的質量是上升的，所以整體還是可靠的。
- 安全性（Secure）
- 可靠性（Reliable）
由於在複用性（DCI模式的應用）、可擴充套件性（模組化）的優勢，介面的一致性很高，開發快速，效能雖然有可能受影響，但體驗還是優秀的。
- 市場時機（Time to Market）
- 客戶體驗（Customer Experience）
（全文完）