《恰如其分的軟體架構:風險驅動的設計方法》——讀書筆記

標籤：des   style   color   使用   strong   sp   問題   on   c   

個人覺得本書概念太多，軟體的架構和開發不是概念拼成的，一些經驗性的東西用合適的詞描述就行。

所謂風險驅動，其實就根據項目情況選擇合適的設計力度，避免過度設計。而對於複雜的軟體系統，精心設計還是非常重要的，在開發前和開發中都會有設計的問題。

另外，對於一個軟體工程師，對一些架構模式需要有些瞭解，在腦海中構建所謂的“概念性模型”，而每個模型都是一定的抽象和受到一些約束。

還介紹了領域模型，設計模型，代碼模型，封裝和分割，模型元素（組件），模型關係。

架構風格，就是所謂的概念性模型。

第二部分值得一看。

 

 

最核心的問題應該是：“對一個特定的系統，應該做多少相應的架構設計工作？”

一個答案：“恰如其分的架構”。

Fairbanks認為，決定架構工作是否充分的核心標準是，看它是否能夠降低風險。如果設計中的風險很小，就不需要做多少架構工作。如果系統設計有很大的問題，架構就是一個很好的工具。本書真正站在工程的角度，從成本和收益方面來選擇技術。尤為可貴的是，它通過關注風險的降低，平衡工程上的收益和進行架構設計的成本，從而獲得最好的結果。

很自然，還有很多派生出來的問題需要回答。

　　哪些風險是最好通過軟體架構來解決的？　

　　如何採用架構設計原理來解決一個設計問題？

　　哪些架構承諾要寫下來以便其他人蔘考？

　　如何確保架構承諾被實現者所遵循？

 0、概述

為瞭解決軟體的複雜度及規模增長帶來的問題，解決思路牽強地歸納為三類：分治、知識、抽象。

　　開發人員把問題分割為規模更小且易於處理的若干子問題，

　　這樣他們就可以運用相似問題的知識來解決某些子問題，

　　而且使用抽象有助於他們進行推理和判斷。

 

我們在構建系統時，應該選擇最符合當前需求的架構，並在該架構的架構下實現功能。

 

概念性模型——抽象與約束  

 

本書建議使用風險(risk)來權衡實施架構的度。 

 

一、風險驅動的軟體架構

 

 

二、架構建模

 

經典的模型結構：領域模型(domain model)、設計模型(design model)與代碼模型(code model)。

　　領域模型對應於真實世界中的事物，

　　設計模型是針對正在構建的軟體所做的設計，

　　代碼模型則對應於原始碼。

我們還可以構建一些額外的模型，用於展現特定的細節，並稱之為視圖(view)。這些視圖可以歸為不同的檢視類型(viewtype)。

 

構建封裝邊界是軟體架構的關鍵技能。組件或模組的使用者通常會忽略內部的工作機制，而將精力放在解決其他難題上。對於封裝好的組件或模組，可以自由地改變其內部實現，而不會影響到它們的使用者。

 

《恰如其分的軟體架構:風險驅動的設計方法》——讀書筆記