架構設計方法論

 

掌握一套架構方法論，掌握規範的設計方法，設計出更好、更穩定的架構設計。

概念解析

在文章開始以前須要先理解幾個概念：

• 什麼是方法論？
  咱們拿到一個輸入，而後根據這個輸入預期一個輸出，把中間這個過程描述出來就是方法論。因此咱們本篇講的架構師方法論就是架構師先拿到通過需求分析出來的輸入，而後完成架構設計，這個過程就是架構設計方法論。

   

• 什麼是設計？
  設計是實現意圖的書面表現形式，而非口頭的東西；
  設計是要讓實現者能理解設計者的意圖，是給別人看而非本身看；
  設計是要讓不一樣的實現者作出來的東西差很少；
  設計是嚴肅的，後續實現者不能隨意偏離設計

   

• 什麼是系統架構師
  做爲系統架構師你須要跳出代碼層面的設計，站在更加宏觀的角度進行把握。
  你關注的是整個系統而不是其中的一兩個查詢模塊，你看到的元素更多的是 ：人 、硬件 、軟件 、網絡。

業務分析

業務分析概述

• 業務分析是在系統開發以前對系統要解決的業務領域的研究過程，目的是搞清楚該業務領域的概念以及業務的運轉過程

• 開發系統的目的通常是爲了優化業務流程，使業務運轉得更加高效、經濟

• 系統的價值主要在於實施後可以幫助客戶帶來多少業務價值

• 無論有無系統，業務一般是不變的

業務分析階段活動模型

業務分析階段是由業務分析師 基於自身的業務知識和相似產品的參考，再結合客戶、領域專家的諮詢和指導輸出業務分析階段的成果，主要包括   領域模型 和 業務模型

領域模型

領域模型是對領域內的概念類或現實世界中對象的可視化表示。又稱概念模型、領域對象模型、分析對象模型。它專一於分析問題領域本 身，發掘重要的業務領域概念，並創建業務領域概念之間的關係。概念比較深奧，其實說白了就是咱們把基於對業務的理解畫成一個類圖，並畫出這些類之間的關係（面向對象），下面咱們看一個實際的領域模型而後加深一下理解。

在領域模型繪製時常常會出現下面兩種典型錯誤：

• 將待開發系統也放在領域模型裏面
  待開發系統要不要出如今領域模型中取決於你的業務離開待開發的系統能不能玩的轉。舉個例子：若是開發的是共享單車的信息系統，共享單車離開信息系統確定玩不轉，因此這時候信息系統須要出如今領域模型。

• 概念劃分不清，關係沒有畫到位
  好比屬性畫成了類，繼承關係搞錯

領域模型的做用

領域模型能夠整理業務中的概念以及關係，幫助團隊中的成員對業務的理解保持一致；日後能夠指導數據庫設計、系統功能設計、指導開發。

如今有種開發模式是基於UI指導開發，根據UI進行數據庫數據庫設計、代碼編寫，咱們稱之爲 「急功近利式」 開發模式。由於UI是系統表面性的東西，是異變的，不穩定的，這種模式下UI變化後咱們的的設計可能也須要跟着變。

而右邊是基於領域驅動開發，在開發前先去思考業務的本質，先把領域層分析出來，再根據分析出來的領域層進行界面設計、架構設計、代碼開發，這是由內而外的設計，這樣作出來的系統就會比較穩定。

業務模型

前面講的領域模型是基於靜態的關係，要理解業務其實更多的須要從動態的角度來了解業務運轉的過程，因此這時候就須要作業務模型。理解業務模型須要先理解如下幾個概念：

業務對象

業務主體主要有 業務執行者、業務工人、業務實體。

要理解這三個對象，咱們首先須要知道什麼是業務，業務是指一個組織能夠向組織外的人提供服務。
業務執行者(Business Actor) ：組織外的人，來享受這個服務的人就稱爲業務執行者；
業務工人(Business worker) ：提供業務的 組織的內部支撐人員
業務實體(Business Entity) ：提供業務的 組織的內部信息系統

理解這幾個概念仍是有點拗口，咱們來看看下面一張圖，一個餐廳對象的業務建模

右邊大的黑框是提供業務的組織，是餐廳；圖的左邊是個業務執行者，是顧客；而在餐廳內部又分爲業務工人（領位員、點餐員、廚師等），業務實體（餐廳點餐管理系統）

咱們在作業務建模時須要注意，全部業務對象在圓圈的右下方須要有個斜線，這是一個建模規範。

業務用例

概念：組織對外提供的業務服務

一個銀行是一個提供業務的組織，這就是業務用例，考察的對象是銀行這個組織而不是系統。

業務流程

業務用例是最基本的定義，而要分析業務動態的過程就須要業務流程，咱們通常用時序圖來表示。

餐廳現狀的業務流程這時候全部的動做步驟所有靠人蔘與

建設系統後的業務流程

有了系統後系統能夠承擔一部分工做，有了系統能改善業務流程、提升價值、下降成本，這就是 建設系統的價值以及意義 ，不然就不必作系統建設了。

業務流程分析的做用

• 動態表達業務運轉的過程

• 只有很好的理解了業務流程，才能設計出更好的支持該業務的系統

• 經過對比系統實施先後的流程變化，分析優化點，評估系統價值

小結

在準備作一個系統以前須要先分析業務，將業務理解清楚。理解業務既有靜態的理解（領域模型）又有動態的理解（業務流程），只有將業務理解清楚才能作出良好的系統。

需求分析

需求分析是需求工程的環節，整個需求工程分爲兩大塊

前期主要是作需求開發，包括需求調研、需求分析、需求定義；後期須要作需求管理，包括需求確認、需求跟蹤、需求變動控制。

我們架構師主要聚焦在 需求分析 和 需求定義 兩個環節。

需求分析階段活動模型

需求分析階段是由系統分析師 基於業務分析師輸出的領域模型、業務模型 再結合 需求調研成果 輸出需求分析階段的成果，主要包括   系統上下文， 功能型需求（用例模型） 和 非功能性需求（性能等）。

系統上下文

系統上下文是指系統與周邊用戶和其它系統之間的關係

系統上下文的繪製很簡單，就是將準備開發的系統畫在中間，把用戶和對接的周邊系統畫出來這就叫系統上下文。

系統用例

系統用例是指系統被使用的案例，主要是從業務流程中推導出來，系統用例的命名規範主要是使用動詞短語，如：添加用戶、查詢話費等短語。

咱們能夠對系統用例細化，如上對登記入座信息這一用例進行細化

系統用例與業務用例的區別與聯繫

• 業務用例是描述組織對外提供的能力，系統用例是描述系統對外提供的能力，二者考察的對象不同

• 系統用例是業務用例相應流程中對系統的一個操做

功能與用例的區別和聯繫

• 用例是需求分析的產物，描述的是某種用戶使用系統完成什麼業務

• 功能是設計階段的產物，是根據系統用例和架構中的組件推導出來的

• 功能是靜態的，用例是動態的

• 從語法角度來講，用例是動詞短語，功能是名詞短語 例：用例命名（查詢空位），功能命名（空位查詢）

• 常見的錯誤：描述需求時拿出一份功能清單

非功能性需求

主要是肯定一些非功能性需求，好比：可用性、 性能、 安全性、 經濟性、可擴展性、 可伸縮性、可移植性等等 可用性、性能、安全性是須要重點關注的內容，咱們後期專門拿出來說。

架構設計（重點）

前面的業務分析與需求分析通常是由其餘專人來作，那麼這一塊的內容則是架構師的工做，須要重點關注。

在系統簡單時咱們須要從 功能角度 對系統進行分解和拆分，這個時候咱們只要作下概要設計和詳細設計就能夠。

在複雜系統時咱們須要從 組件角度 對系統進行分解和拆分，這個時候咱們就須要作架構設計與概要設計。

組件、功能、模塊

組件是架構設計階段考慮的單元（進程級別），功能、模塊是概要設計、詳細設計考慮的單元；一個組件可包含多個模塊，涉及多個功能；一個功能的實現可能須要多個組件中的相應模塊來協做完成。

咱們用一張圖來理解他們三者之間的關係 

先後端分離的一個項目從進程角度劃分出三個組件，分別是web前端、後端接口服務、後臺服務， 爲了實現用戶查詢這個功能必需要在相應組件裏都須要有相應的模塊

一個組件裏能夠有多個不一樣的模塊，各個組件裏的模塊相互協做完成某一個功能

架構

若是用一句話來描述什麼是架構，那應該能夠這樣定義：架構是系統的內部結構（組件以及它們之間的關係）還要包含系統的技術要素。作架構設計其實就是幹這兩件事。

架構設計有兩個目標：

• 知足功能性需求

• 知足非功能性需求

架構設計階段活動模型

架構設計階段是由系統架構師 參照需求分析的產物（SRS），再經過對系統分析師、項目經理的諮詢輸出架構設計階段的成果，主要包括   架構工做計劃 、 邏輯架構、物理架構、開發組件一覽表、部署組件一覽表、技術選型一覽表

那如何來衡量一個架構的設計好壞呢？

在設計完成時咱們能夠經過設計資料的規範性以及設計思路、方案決策、技術選型的合理性來校驗；
在系統實現後能夠經過功能性和非功能性需求的知足程度來校驗。

邏輯架構設計（非技術型）

• 將系統從非技術角度分解成若干邏輯組件，並創建它們之間的關係，以知足系統需求。關係分靜態和動態，其中靜態關係用組件圖表示，動態關係用序 列圖表示。

• 邏輯架構中，組件名稱使用母語以便理解

• 邏輯架構不涉及技術元素，只是純概念上的表述

• 邏輯架構的讀者能夠是非技術人員

• 邏輯架構設計完成後應和系統分析師、產品經理等人員一塊兒確認，檢查是否知足需求

咱們看一個典型的邏輯架構

物理架構設計（技術型）

• 將邏輯架構中的組件轉換爲技術性的物理組件，名稱使用英文，在實現時應遵循這些命名

• 物理組件粒度有大有小，可表現爲子系統、進程、對象等多種形式

• 物理架構還須要解決非功能性需求

• 物理架構還要和後續設計和實現進行銜接

• 非技術人員可能難以理解

咱們看一個典型的物理架構

小結

架構設計爲系統的整體設計，決定了系統的組件劃分、關鍵技術方案決策、技術選型 架構設計上接需求，下接進一步的設計和實現，是決定系統實現的質量、效率、成本的關鍵階段

概要設計與詳細設計

概要設計

概要設計階段的主要內容是進行功能模塊劃分以及接口定義（接口名稱、功能概要、參數、返回值）

概要設計階段活動模型

概要設計階段是由開發組長 基於系統用例、開發組件一覽表 再結合對架構師和系統分析師的諮詢輸出概要設計階段成果，主要包括  功能一覽表 ， 接口說明書。

詳細設計

詳細設計階段的主要內容是描述內部模塊實現、界面設計以及數據庫設計

詳細設計階段活動模型

詳細設計階段可能會根據工做內容進行分工，主要結合以前的產出輸出詳細設計階段的成果，主要包括  界面設計 ， 模塊內部設計 ， 數據庫設計。

後續工程階段

開發階段活動模型

開發階段主要是由開發人員結合架構設計的產物以及詳細設計的產物編寫相應代碼。

測試階段活動模型

測試階段主要是由測試人員結合架構設計的產物以及詳細設計的產物進行功能測試，包括功能性需求以及非功能性需求，須要對外輸出 測試計劃，測試用例 以及 測試報告。

部署階段活動模型

部署階段主要是由部署人員結合架構設計的產物以及跟開發人員的諮詢進行組件部署，這一階段須要輸出部署計劃、部署方案、部署手冊、部署腳本、部署實施 等

運維階段活動模型

運維階段主要是由運維人員結合架構設計的產物進行系統運維，須要輸出運維計劃、運維方案、運維手冊、運維腳本、運維報告 等。

 

以上，但願對你有所幫助！

 

 

 

 

 

 

 

 

本文分享自微信公衆號 - JAVA日知錄（javadaily）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。