1、框架的通用作用及層面：
軟件開發要滿足用戶的功能性需求，只有在滿足了功能性需求的前提下，非功能性需求才算有價值的。可以歸納出軟件開發的兩大需求：功能性需求，非功能性需求。前者優先級高。
功能性需求可以用各種方式實現，在滿足功能性需求後，需要完成非功能性需求，非功能性需求形態各異：安全、性能、穩定性、易維護、易伸縮。在滿足了功能性需求後，這些將變成重點考慮的範圍。
框架的主要作用就是讓我們更好的實現非功能性的需求，因爲非功能性需求直接影響這功能性需求的使用。良好的用戶體驗、良好的視覺效果，這些都是現代軟件所必須的。
2、 框架的生命週期：
現代應用軟件的需求發生翻天覆地的變化，從功能性需求到非功能性需求都在飛快地發展和創新，框架所在的位置就必然要求他能夠快速滿足這些不斷變化的上層需求。能夠快熟的支撐上層需求變化是考驗框架的整體指標之一。
非功能性需求的一個特點就是不變性。這些需求可能在任何一個軟件系統中都會需要。但在功能性需求是各不相同的。每個軟件系統都有各自的業務需求，儘管大體相似，但在業務細節的處理上還有很大差別。
所以非功能性需求是完全可以在多個系統之間複用，即非功能性需求可以複用，那麼用來支撐的框架也就可以複用了。
框架在其生命週期中，爲了滿足各種需求，需要不斷的維護。在多個系統中複用框架，必然會出現很多定製化需求，所以框架在其生命週期中需要經常修改，這樣才能保持框架的重要價值。因此框架並不是固定不變的。
3、框架設計：
框架設計有着複雜的過程，每一步都需要嚴格把關。這是因爲框架設計在系統架構中舉足輕重，他的修改對系統的衝擊很大，會牽一髮而動全身，所以對框架設計的要求要高出一般業務功能，只有這樣才能保證框架的最終質量。
3.1 確定問題域和識別變化點、
首先需要確定問題域，問題域也就是你將要用框架來解決的問題範圍，有了範圍之後我們纔可以針對每個點進行詳細的分析。例如通信框架，首要是確定業務範圍，他允許哪些類型的消息通過該框架，在腦海中需要有一個大致的範圍。
Client<=>通信框架<=>Servie。
確定了大概的問題域之後，就可以進一步分析他的變化點。變化點的整理何以讓我們更細緻的瞭解架構，這對後面的架構選擇很重要，因爲架構模型是由架構模式驅動出來的，正所謂模式驅動模型，模型驅動設計。模式是對莫一類固定問題的求解方式和方法，是經驗的總結。確定了問題域之後，我們就可以選擇相應的模式來驅動出符合當前問題域的框架架構。
<=================================變化點 ==============================>
Client<=傳入/接受消息=> <= 通信接口<=>安全<=>壓縮<=>通信框架<=>壓縮<=>安全<=>通信端口=><=傳入/接受消息=>Service
3.2 選擇合適的架構模式、配置變化數據、可視化管理
選擇架構模式的前提是你已經確定了問題域並且識別出了大部分的變化點，這樣我們才能準確的選擇架構模式。通常一種模式對應一種問題的解決方法，在必要情況下需要組合多個模式來搭建一個符合當前問題域的模式。（如果你識別出來的變化點夠詳細，可以考慮是否需要組合多個模式來完成一個架構模式）
通過上面的問題域和變化點，可以大概得知將使用如下幾種模式：
1、通信框架：管道模式
2、消息：契約式設計
3、通信端口：異步消息+事件驅動
4、安全：鏈接式編程
5、壓縮：：ICO注入第三方壓縮方法
設計好架構之後，就需要將變化點配置起來，以便在需要的時候動態的切換變化點。配置的方式基本上有兩種，一種是在本地通過靜態文件的方式，另一種是通過遠程服務動態配置的方式。兩種方式對應不同的場景。靜態配置通常用在無需及時更新的時候，而遠程動態配置是需要在運行時動態的調用隨時會變化的配置，如促銷價格及折扣率。
框架設計中另一個很重要的部分就是可視化。大部分框架都會忽略可視化部分的設計，其實是不正確的。一個完整的框架必須配備可視化工具來幫助我們方便的使用框架和管理框架。（例：上述框架中添加可視化工具跟蹤和查看框架中的消息，便於我們在測試的時候查看消息的狀態，修改消息的內容）
作爲一個完善的框架，不僅需要在運行時穩定，而且也要保證該框架的可測試性。若能做到在測試時，框架內部是透明的，那麼將大大提高框架的受歡迎度。
4 、框架設計核心三元素：模式、配置和工具
4.1 框架模式：
框架模式是一套針對框架設計而言的解決方法，不同的模式解決不同的問題域。你可以使用單一的模式解決一個單一的問題，也可以使用一整套模式來解決一個複雜的問題。
不同的模式最終會驅動出不同的模型出來，而模型就是框架的最終架構。有了模式之後，我們所關心的就是該模式如何用代碼實現。熟練掌握這些模式能讓你在框架設計上得心應手，因爲每種框架都有一套與之對應的模式，只要熟練這一套模式、模型及代碼實現，你很快就會判斷出該問題域所使用的模式。
4.2 框架配置：
框架的設計必然少不了對一些數據和邏輯的配置。配置的設計也是相當複雜的，設計配置的存放位置、讀取方式、配置信息的生成方式，這些都將決定框架內部如何與這些配置信息協調工作。
大部分框架在設計配置部分的時實現方式都比較單一，缺乏靈活性，在框架讀取配置信息的時候也比較生硬，不夠平滑。所以配置部分的設計將是框架整體設計的重要元素之一。
4.3 框架工具：
框架的可視化部分非常重要，尤其是在現代大型企業級應用架構中，任何一個地方出現問題都會引起一些連鎖反應，這個時候我們急需使用工具來定位到問題，或者起碼要幫助我們定位到問題。
工具需要在一下幾個方面提供對框架使用的支持：
1. 開發時：可視化編程已經不是新概念了。要在開發是帶有部分可視化自動完成的功能，最後是集成在Visual Studio 中的插件，這取決於框架的使用方式。
2. 編譯時：企業級分佈式框架需要在很多環境中運行，在測試階段需要在測試環境中運行，在發佈到生產線之後就需要在真實的環境中運行，不同的環境，需要配置不同的環境信息，測試環境可能不存在負載均衡，而在真是環境中會有集羣，這個時候就需要我們在使用框架編譯時能夠生成一些環境變量信息。
3.運行時：運行時的工作責任重大，日誌、監管、調試等功能都需要框架提供，有了這些功能，我們對框架使用纔會更有信心。
總結：在一般的框架設計中，配置、工具一般不會被提及，但在企業級框架中，這兩項就顯得極爲重要，是衡量框架是否健全的重要標準。
模式是骨架，配置是變化點，工具是輔助管理。從框架的架構到變化的配置再到框架的使用工具，這纔是一條正確的框架設計指導路線。
（源自《.NET 框架設計》）