《一線架構師實踐指南》第三部分閱讀筆記

概念性架構界定系統的高層組件，以及它們之間的關係。概念性架構意在對系統進行適當分解，而不陷入細節。藉此，能夠與管理人員、市場人員、用戶等非技術人員交流架構。概念性架構規定了每一個組件的非正式規約及架構圖，但不涉及接口細節。

 Refined Architecture相對於Conceptual Architecture而言，分別對應於「概念級」解決方案和「規約級」解決方案。Refined Architecture（細化架構）屬於架構設計，不能與Detailed Design（詳細設計）相混淆。

細化架構（Refined Architecture）階段（RA階段）
細化架構階階段的5視圖方法：

整體步驟：

多視圖的方法不單單是架構歸檔技術，更是指導咱們進行架構設計的思惟方法。

 

越是複雜的系統，越是須要從多個方面進行架構設計，這樣才能把問題研究和表達清楚，而提供不一樣的軟件架構視圖也便於交流和傳遞設計思想。

 

關鍵需求是對軟件架構設計起關鍵做用的需求子集，包括功能需求、質量需求和商業需求三種，架構細化必須注意知足這些需求。

 

領域模型是以面向對象方式對問題領域的模型的模擬和抽象，它揭示了重要的業務領域概念，並創建業務領域概念之間的關係，領域模型被不斷精化後成爲最終軟件系統的問題領域層，它決定了軟件系統的功能範圍，並影響着軟件系統的可擴展性。

 

概念性架構是對系統設計的最初構想，經過主要的設計元素及它們之間的關係來描述系統，這些高層次的設計選擇對將來軟件系統的質量和功能都有關鍵做用。

 

約束能夠視爲一類特殊的需求，它們具備強制性，規定了業務和技術上的標準和限制。

 

咱們利用架構視圖的方法，從邏輯架構、開發架構、運行架構、物理架構和數據架構五個方面來進行架構設計。

 

設計邏輯架構：使用UML來描述，靜態方面包括包圖、類圖、對象圖；動態方面包括序列圖、協做圖、狀態圖和活動圖。

 

邏輯架構的設計應該完成的工做：

1. 細化功能單元
2. 發現通用機制
3. 細化領域模型
4. 肯定子系統接口和交互機制

 

由於軟件架構的重點在於‘軟件系統的各部分是如何相關的’，那麼咱們能夠通過適度的抽象分析，將幾組協做中的公共行爲提取出來成爲‘通用機制’，這樣用利於全部涉衆對軟件架構的共同認識——即提升了系統的概念完整性。

 

什麼是機制？所謂機制，是模式的實例，機制必須進一步細化才能成爲特定模型中的協做，所以，機制是獨特上下文中重複出現的問題的特定解決方案。能夠說，機制符合模式的定義，任何協做均可以被稱爲機制，但一般，機制僅表示‘軟件應用系統中重複出現的問題的解決方案’的協做，例如能夠採用模式的持久化處理等等。

 

具備良好架構的系統具有概念完整性，它經過對系統架構創建一種清晰的認識來發現通用的抽閒機制，利用這種共性使得最終產生的系統結構更加簡單，於是規模更小且更可靠。一個系統使用10000行代碼實現遠比1000000行代碼好的多。

 

一流是每一個程序設計人員嚮往併爲之奮鬥卻又沒法具體說出的、難以達到的境界。一流的軟件很是簡明，它靈活而清晰，能經過創造性的機制解決複雜的問題，這些機制語義豐富，能夠應用於其餘可能徹底無關的問題。一流意味着尋求恰當的抽象，意味着經過新的途徑合理利用有限的資源。

 

設計開發架構：着重考慮開發期間的質量屬性，例如可擴展性、可重用性、可移植性等，開發架構的關注點是在軟件開發環境中軟件模塊的實際組織方式，具體涉及源程序文件、配置文件、源程序包、編譯後的目標文件、第三方庫文件等。使用UML進行描述的話，涉及到包圖、類圖、組件圖等。

 

開發架構的設計工做包括：

1. 肯定要開發或直接利用的程序包之間的依賴關係
2. 肯定採用的技術
3. 肯定採用的框架

 

設計數據架構：着重考慮‘數據需求’，系統=程序+數據+硬件。數據架構的關注點是持久化數據的組織，對於不少集成系統，數據須要在不一樣系統之間傳遞、複製、暫存等，這每每涉及到不一樣的物理機器。數據架構的描述通常採用E-R圖和數據流圖來表示，採用UML時，涉及到類圖和活動圖。

 

數據架構的設計工做包括：

1. 持久化數據存儲方案
2. 數據傳遞、數據複製、數據同步等策略