視圖 spl 基類 trac 增加 必須 面向服務 oop 中介者模式

更新說明 本篇文章已經整理完很長時間，總感覺有些不足，因此一直沒法，希望潤色後再發，深感自己水平有限，遲遲沒有動筆。但是收到多位朋友的邀約，思考再三決定逐步完成本系列文章。其中不足，請批評指正，我們一起進步。 內容摘要 主要從架構方法論，系統劃分，架構原則，通用模式，架構視圖，幾個方面。整體上介紹了架構相關的知識領域，在此基礎上，可以有目的的學習相關資料。 本篇主題 2.1架構方法論：面向過程，面向對象，面向方面，面向服務 2.2系統劃分：系統，子系統，模塊，功能，接口 2.3架構基本原則：場景化，抽象， 通用專用，高內聚，松耦合 ，職責劃分，關註點分離， 分層架構等 2.4模式：設計模式，架構模式，基礎設施模式 2.5架構視圖：4+1視圖 一、架構方法論 在架構領域主要包括面向過程，面向對象，面向方面，面向組件，面向服務等方法論。每種方法關註的點有所不同。並伴隨著軟件工程和系統規模逐漸演化。具體使用哪種方式，需要根據實際場景，進行合理的技術選型。以下將綜合介紹，主流編程方式的相關知識總結。 1.1面向過程（Procedure-Oriented Programming ） 結構化編程思想的核心：功能分解（自頂向下，逐層細化）。將一個大的問題劃分為幾個小的問題，再將幾個小的問題劃分為更小的問題，我們解決大問題非常困難，但是解決劃分後的最小的問題卻比較容易。 面向過程編程把編程任務劃分成一個一個的步驟，然後按照步驟分別去執行。其中每完成一個步驟就像是完成一個任務中的單個過程一樣。 公式：程序=算法+數據結構 關註：流程，函數，庫文件 優點：記賬式代碼，容易理解 缺點：與業務流程強耦合，復用性差 代表語言：Basic，C 1.2面向對象（Object-Oriented Programming） 面向對象編程（Object-Oriented Programming）簡稱OOP技術。面向過程編程常常會導致所有的代碼都包含在幾個模塊中，使程序難以閱讀和維護。在做一些修改時常常牽一動百，使以後的開發和維護難以為繼。而使用OOP技術，常常要使用許多代碼模塊，每個模塊都只提供特定的功能，它們是彼此獨立的，這樣就增大了代碼重用的幾率，更加有利於軟件的開發、維護和升級。 在面向對象中，算法與數據結構被看做是一個整體，稱作對象，現實世界中任何類的對象都具有一定的屬性和操作，也總能用數據結構與算法兩者合一地來描述，所以可以用下面的等式來定義對象和程序： 對象=（算法+數據結構），程序=（對象+對象+……） 從上面的等式可以看出，程序就是許多對象在計算機中相繼表現自己，而對象則是一個個程序實體。 面向對象編程思想的核心：一切皆對象，抽象，復用，提高靈活性 面向對象編程思想主要是復用性和靈活性（彈性）。復用性是面向對象編程的一個主要機制。靈活性主要是應對變化的特性，因為客戶的需求是不斷改變的，怎樣適應客戶需求的變化，這是軟件設計靈活性或者說是彈性的問題。 公式：程序=對象+交互【對象=（算法+數據結構），程序=（對象+對象+……）】 關註：抽象，對象，類，繼承，封裝，多態 優點：復用性，擴展性，靈活性，維護性 缺點：對象化將簡單的問題復雜化，不能解決公用橫切代碼問題 代表語言：Java，C# 方法論： OOA: Object Oriented Analysis 面向對象分析方法 OOD:Object Oriented Design 面向對象設計 OOP: Object Oriented Programming 面向對象的程序開發 1.3面向組件（Component-Oriented Programming） 面向對象支持重用，但是重用的單元很小，一般是類；而面向組件則不同，它可以重用多個類甚至一個程序（組件）。也就是說面向組件支持更大範圍內的重用，開發效率更高。如果把面向對象比作重用零件，那麽面向組件則是重用部件。 COP比OOP更進一步。通常OOP將數據對象組織到實體中。這種方法具有很多優點。但是，OOP有一個大的限制：對象之間的相互依賴關系。去掉這個限制的一個好的想法就是組件。組件和一般對象之間的關鍵區別是組件是可以替代的。 公式：程序=組件+交互 關註點：功能模塊 優點：將系統組件化設計，提高復用性 缺點：增加了組件維護和升級成本 代表框架：OSGI 1.4面向方面（Aspect-Oriented Programming） 將通用需求功能從不相關類之中分離出來；同時，能夠使得很多類共享一個行為，一旦行為發生變化，不必修改很多類，只要修改這個行為就可以。 AOP就是這種實現分散關註的編程方法，它將“關註”封裝在“方面”中。 基本定義：將通用功能與業務邏輯分離 關註點：切面，通知，連接點，織入 實現技術：動態代理 代表框架：Spring AOP 1.5面向服務（Service-Oriented Programming） SOP是一種體系結構，目標是在軟件代理交互中獲得松散耦合。一個服務是一個服務提供者為一個服務消費者獲得其想要的最終結果的一個工作單元。服務者與消費者都以軟件代理代表他們自己的角色。 這聽起來有些太抽象，但是SOP確實無處不在。讓我們在你的住房中找到一個SOP的例子。例如播放一個CD,你可以將要播放的CD放入CD機中，CD機將為你播放這張CD，CD機提供了一個CD播放服務。這裏的好處就是你可以用不同的CD機去播放同一張CD。他們能提供同樣的CD播放服務，但是服務質量是不同的。 SOP的思想明顯不同於面向對象的編程，面向對象編程強烈的建議你應該將數據與其操作綁定。因此在面向對象編程風格中，每張CD 有它自己的CD播放機，他們之間不能被拆開。這聽起來很奇怪，但是這就是我們建立許多已存軟件系統的方式。 而SOP就不一樣了，為了減少異構性、互操作性和不斷改變的要求的問題，這樣的體系結構應該提供平臺來構建具有下列特征的應用程序服務： 松散耦合、位置透明、協議獨立 基於這樣的面向服務的體系結構，服務使用者甚至不必關心與之通信的特定服務，因為底層基礎設施或服務“總線”將代表使用者做出適當的選擇。基礎設施對請求者隱藏了盡可能多的技術。特別地，來自不同實現技術（如 J2EE 或 .NET）的技術規範不應該影響 SOP用戶。如果已經存在一個服務實現，我們就還應該重新考慮用一個“更好”的服務實現來代替，新的服務實現必須具有更好的服務質量。 公式：系統=服務+交互 關註點：服務化，業務拆分，獨立部署，服務粒度 演變：Rpc，服務框架，服務治理，微服務 優點：提供業務粒度的復用組件，可以有效利用資源提高性能 缺點：維護，部署成本高，需要自動化 代表框架：Dubbo，Zero Ice，Spring boot 二、系統拆分 要解決復雜系統的架構問題，在需求分析的基礎上，要首先進行系統的拆分，將大系統拆分為小的系統，小的系統拆分為模塊。采用分而治之的方式，進行系統架構設計。關於拆分的粒度與實際的項目和團隊情況，有所差異。本節只介紹通用的系統拆分方法。 系統的拆分可以按照縱向和橫向切分，縱向是指按照業務系統或功能模塊進行拆分。橫向是按照分層架構進行切分。 2.1垂直拆分（縱向） 縱向切分可分為：系統，子系統，模塊，功能，接口 系統： 子系統：根據職責劃分的，具有不同的業務意義切分的系統。比如用戶子系統，訂單子系統。 模塊：實現某一個功能的集合，解決某一特定問題。比如會員模塊。 功能：模塊中的一個功能點，實現某種能力，比如會員註冊功能。 接口：對外暴露，提供對外訪問自身功能的能力。 縱向切分是從粗到細的過程，經過分析很好的定義了系統的功能分解結構。可根據分解結構，進行功能細化或項目預估。 2.2水平拆分（橫向） 橫向切分可按照物理或邏輯方式切分，物理切分是指將一個系統進行橫向切分後的每一層或多層一起部署，每個部署實例代表一層或多層。比如接入層，服務層，資源層等。 邏輯切分是不考慮實際部署，從系統的邏輯角度出發進行分層。可分為表現層，業務層，資源整理層，資源層。具體的部署，可能是集中也可能是分開部署。 設計要點：每一層都有自己的邊界，關註點和職責，上層依賴底層，避免跨層調用。 三、架構基本原則 架構設計，需要依據一些基本原則進行設計，在原則的基礎上進行權衡，取舍，獲得最終的架構決策。本節介紹，幾種常用的架構原則。 場景化：每個需求都應該有適應的場景，基於場景進行設計，避免無目標或設計過渡。 抽象：將具體的事物，根據共性進行抽象，將公有行為抽象為接口，將共有邏輯抽象為基類。 高內聚：指部件的內部關系，將屬於自己的屬性，行為進行封裝，對外暴露必要的接口。當內部改變時，不影響外部的使用。 松耦合：指部件之間的依賴關系，應該是弱依賴，而不是強依賴，可通過接口或異步實現解藕。 關註點/職責分離：將不同職責或關註點不同的進行拆分，使其只負責自己的事情，而不負責其他的事情。基本要求是分離不相關的，分離不穩定的。 分層架構：將系統進行物理層和邏輯層拆分，每層只關註自己負責的事情，並提供對外訪問接口。分層可以將系統進行拆分，易於層級復用，代碼維護性好，可根據工種分工。 通用專用：將通用部件和專用部件進行拆分，降低耦合度，提高復用性和可維護性。 平衡：沒有最好的架構，只有更合適的架構，權衡需求，技術，約束，質量，成本等影響因素做出最好的決策。是架構師必須把握的第一方法論。 其他原則：SOLID 四、模式 模式是針對某一問題的通用解決方案，是前人智慧的結晶。通過應用模式，可以快速有效的找到最佳解決方案。系統架構中涉及三種模式，設計模式，架構模式，基礎設施模式，分別解決代碼結構，系統結構以及網絡和硬件部署的問題。 4.1設計模式 解決的問題：代碼設計層面，通用問題的通用解決方案。 模式分類：創建型（5），結構型（7），行為型（11） 創建型：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。 結構型：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。 行為型：策略模式、模板方法模式、觀察者模式、叠代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。 模式匯總：借用一張圖：出處（23種設計模式全解析）：https://www.cnblogs.com/geek6/p/3951677.html

4.2架構模式 解決的問題：確定系統中關鍵架構設計的架構和交互機制。 模式分類：

1、模塊結構(From Mud to Structure)型。幫助架構師將系統合理劃分，避免形成一個對象的海洋。 包括 Layers （分層）模式、 Blackboard （黑板）模式、 Pipes/Filters （管道/過濾器）模式等。

2、

分散系統（Distributed Systems）型。為分散式系統提供完整的架構設計，包 括像 Broker（中介）模式等。

3、人機互動（Interactive Systems）型，支持包含有人機互動介面的系統的架構設計，例子包括 MVC（Model-View-Controller）模式、PAC （Presentation-Abstraction-Control）模式等。

4、

Adaptable Systems 型， 支持應用系統適應技術的變化、 軟件功能需求的變化。 如 Reflection（反射）模式、Microkernel（微核）模式等。

模式小結：此圖出處（10種常見的軟件架構模式）：https://www.cnblogs.com/IcanFixIt/p/7518146.html

4.3基礎設施模式 解決的問題：硬件，網絡等底層設計和基礎架構問題。 模式分類：涉及硬件，網絡，中間件，安全等方面。 可詳見書籍《基礎設施設計模式》

五、架構視圖

架構視圖是從不同的涉眾看問題的角度出發，設計符合不同涉眾需求的架構設計方案。用於全面，精確的分析和設計符合不同涉眾要求的系統架構。業界使用比較多的是4+1視圖。

5.1邏輯視圖 邏輯架構的目的是職責的劃分，並明確其與協作關系；其中職責的劃分註意邏輯的分層、子系統以及關鍵類的定義；協作的定義關註接口的定義與協作關系的明確。 5.2開發視圖 開發架構的目的是確定程序單元以及程序單元的組織結構；其中程序單元包括源文件、配置文件、程序庫、框架、目標單元；程序單元組織包括project劃分、project目錄結構、編譯依賴關系。 5.3數據視圖 數據架構的目的是確定要存儲的數據以及存儲格式；其中存儲的數據可以是文件、關系數據庫、實時數據庫；存儲格式包括文件格式、數據庫圖表 5.4物理視圖 物理架構的目的是確定物理節點和物理節點的拓撲結構；其中物理節點包括服務器、PC機、專用機、軟件安裝部署燒寫以及系統軟件的選型；拓撲結構明確物理節點的關系。 5.5運行視圖 運行架構的目的是確定控制流和控制流的組織；其中控制流包括進程、線程、服務程序；控制流組織包括系統的啟動與停機、控制流通訊、同步與加鎖。 六、擴展知識 本部門內容可自行學習了解。 6.1插件架構和開發 6.2微服務架構 6.3UML建模 七、本篇總結 主要從架構方法論，系統劃分，架構原則，通用模式，架構視圖，幾個方面。整體上介紹了架構相關的知識領域，在此基礎上，可以有目的的學習相關資料。 八、參考資料 從面向過程到面向對象:http://blog.csdn.net/hjf19790118/article/details/6919578 面向對象編程（OOP）、面向組件編程（COP）、面向方面編程（AOP）和面向服務編程（SOP）:http://blog.csdn.net/ocean181/article/details/6720371 面向對象，面向組件，面向接口，面向方面，面向服務編程的一些比較 http://chunniux.blog.163.com/blog/static/148497192012012101549604/ 面向對象程序設計與面向過程程序設計解析 http://blog.csdn.net/tianfeng701/article/details/8040304 軟件架構設計-五視圖方法論:https://blog.csdn.net/nnsword/article/details/78109126 軟件架構設計-五視圖方法論:https://www.cnblogs.com/hongbo819/p/4871412.html 九、下篇預告 第三篇 UML建模 3.1架構模型 3.2靜態模型 3.3動態模型 3.4建模案例

從零開始學架構（二）架構知識領域