學(xué)習(xí)面向?qū)ο缶幊趟枷霑r我們知道面向?qū)ο笥腥筇卣鳎宕蠡驹瓌t，三大特征是判斷一種語言是否只是遵守面向?qū)ο笏枷氲囊罁?jù)，而五大基本原則是軟件設(shè)計以及開發(fā)的基本準(zhǔn)則。很多書上都有講解五大基本原則，但對遵守五大原則的原因所述不詳。但其實五大基本原則不止可以應(yīng)用到面向?qū)ο筌浖墓δ茉O(shè)計上，在做架構(gòu)設(shè)計時，更是要思考架構(gòu)是否和五大基本原則的思想相悖，無論是側(cè)重于復(fù)雜業(yè)務(wù)功能的傳統(tǒng)軟件公司還是側(cè)重于保證系統(tǒng)可用性以及并發(fā)性的互聯(lián)網(wǎng)公司，其軟件架構(gòu)設(shè)計都不應(yīng)輕易打破五大原則得設(shè)計原則。

1 面向?qū)ο?/h1>

1.1 單一職責(zé)原則

單一職責(zé)原則（Single-Responseibility Principle），從面向?qū)ο蟮脑O(shè)計上思考，一個類的功能只有一個，即引起這個類變化的原因只有一個，對于架構(gòu)設(shè)計來說，單個服務(wù)或者單個模塊只負(fù)責(zé)處理一件事，將與此事相關(guān)的業(yè)務(wù)封裝在此模塊內(nèi)部，在功能上高內(nèi)聚，盡量減少和其他模塊的耦合度。遵守單一職責(zé)原則的好處是能消除耦合，從軟件設(shè)計上來看能減少因需求變更帶來的代碼維護(hù)增加的工作量，從架構(gòu)設(shè)計上看能減少單個模塊故障的波及范圍。

1.2 開放封閉原則

開放封閉原則（Open-Closed Principle），對擴(kuò)展開發(fā)，對修改關(guān)閉，也就是說設(shè)計時，應(yīng)開放系統(tǒng)有可能出現(xiàn)的擴(kuò)展點(diǎn)，而對不會變更的功能的修改關(guān)閉。開閉原則是面向?qū)ο罂蓮?fù)用設(shè)計的基石，同樣在架構(gòu)時也需要考慮系統(tǒng)的擴(kuò)展性。

1.3 里氏替換原則

里氏替換原則是基于面向?qū)ο蟮睦^承特征，遵循此原則能使軟件更加靈活，也能降低因需求變更對系統(tǒng)的影響范圍。從架構(gòu)設(shè)計的角度來看，模塊的版本迭代應(yīng)兼容之前的版本。

1.4 依賴倒置原則

依賴倒置原則，高層模塊不應(yīng)依賴于底層模塊，他們都應(yīng)依賴于抽象。使用多個專一的接口比是用一個總的接口要好，對客戶類來說對另一個類的依賴應(yīng)當(dāng)建立在最小接口上。遵循此原則不會強(qiáng)迫客戶依賴他不使用的方法，能減少耦合度，增加系統(tǒng)靈活度。

1.5 接口隔離原則

接口隔離原則要求，各個模塊依賴與抽象，而不依賴與實現(xiàn)，面向接口編程而不是面向?qū)崿F(xiàn)編程，好處是能降低耦合度。

綜上，五大原則的目的都是為了降低系統(tǒng)耦合度，增強(qiáng)系統(tǒng)擴(kuò)展性，模塊內(nèi)部高內(nèi)聚，模塊之間低耦合，同樣架構(gòu)設(shè)計時需要遵守的原則也是降低模塊之間耦合度，增強(qiáng)擴(kuò)展性，低耦合、高內(nèi)聚能降低系統(tǒng)否則度，降低開發(fā)時溝通成本，降低上線后的網(wǎng)絡(luò)成本。

2 面向架構(gòu)

2.1 面向架構(gòu)設(shè)計的“5+1”模型

“5+1”架構(gòu)視圖

• 用例視圖（應(yīng)用場景角度）
• 邏輯架構(gòu)視圖（功能需求角度）
• 開發(fā)架構(gòu)視圖(開發(fā)角度）
• 運(yùn)行架構(gòu)視圖（運(yùn)行時）
• 物理架構(gòu)視圖（運(yùn)維）
• 數(shù)據(jù)架構(gòu)視圖（持久化）

軟件架構(gòu)設(shè)計應(yīng)是從多個角度的思考，但各個角度都應(yīng)圍繞著應(yīng)用場景和功能需求，即圍繞用戶來展開。用戶視圖的的缺失會導(dǎo)致開發(fā)的軟件與需求不相符，無法滿足用戶使用；開發(fā)視圖的缺失會導(dǎo)致開發(fā)之間無休止的溝通，會不斷的重復(fù)造輪子，使得越開發(fā)系統(tǒng)越復(fù)雜，最后很可能導(dǎo)致開發(fā)失敗。運(yùn)行架構(gòu)的缺失會導(dǎo)致系統(tǒng)頻繁故障，無法保證可用性。物理架構(gòu)缺失會導(dǎo)致系統(tǒng)上線、下線困難，bug難以定位，故障排查困難。數(shù)據(jù)架構(gòu)缺失會導(dǎo)致系統(tǒng)數(shù)據(jù)丟失，或數(shù)據(jù)出錯，影響數(shù)據(jù)完整性，更嚴(yán)重的可能會造成重要數(shù)據(jù)丟失，難以恢復(fù)，造成難以估量的損失。

3 常見的幾種軟件架構(gòu)模式

3.31分層架構(gòu)

1. 靈活性較低
2. 易于部署
3. 可測試性高
4. 性能低（相對來說）
5. 伸縮性低
6. 易于開發(fā)

分層架構(gòu)是的主要目的還是在于層內(nèi)部的高內(nèi)聚，層之間的低耦合，降低開發(fā)的服務(wù)度。

3.2 SOA架構(gòu)

SOA架構(gòu)是一種開發(fā)視圖架構(gòu)，SOA架構(gòu)的原則：

1. 服務(wù)封裝
2. 服務(wù)松耦合
3. 服務(wù)契約
4. 服務(wù)抽象
5. 服務(wù)的可重用性
6. 服務(wù)的可組合性
7. 服務(wù)自治
8. 服務(wù)無狀態(tài)
9. 服務(wù)的可被發(fā)現(xiàn)性

SOA側(cè)重于服務(wù)的封裝以及可重用，更像是對系統(tǒng)的一種水平拆分產(chǎn)生的架構(gòu)模型，就像是分層架構(gòu)下將某個層或者某個層的某一塊作為一個單獨(dú)的服務(wù)，是高內(nèi)聚思想的一種體現(xiàn)。

3.3 微服務(wù)架構(gòu)

1. 擴(kuò)展性好，各個服務(wù)之間低耦合
2. 容易部署，軟件從單一可部署單元，被拆成了多個服務(wù)，每個服務(wù)都是可部署單元
3. 容易開發(fā)，每個組件都可以進(jìn)行持續(xù)集成式的開發(fā)，可以做到實時部署，不間斷地升級
4. 易于測試，可以單獨(dú)測試每一個服務(wù)

相比于SOA，微服務(wù)是一種用戶視圖架構(gòu)，微服務(wù)是對系統(tǒng)的一種垂直拆分的架構(gòu)模型，是一種低耦合思想的體現(xiàn)，微服務(wù)側(cè)重于版本的快速迭代，微服務(wù)的另一個好處是單個業(yè)務(wù)模塊的故障不會波及整個系統(tǒng)，降低了故障的影響范圍，從這方面將它也是一種運(yùn)行視圖架構(gòu)。微服務(wù)不是把服務(wù)做小了就是微服務(wù)，微服務(wù)的核心是從業(yè)務(wù)的角度降低個模塊之間的耦合度。對于中小企業(yè)來說微服務(wù)架構(gòu)的成本較高，設(shè)計難度較大。

總結(jié)

另外還有微內(nèi)核架構(gòu)、事件驅(qū)動架構(gòu)，有興趣可閱讀《Software Architecture Patterns》一書。關(guān)于面向?qū)ο笪宕笤瓌t的理解講的不是很清楚，但這個確實比較難以言傳，如果身邊有寫代碼的架構(gòu)師，可以多閱讀他們的代碼，或者可以閱讀一些開源組件的源碼，對理解設(shè)計思想會有好處。