原著名稱《.NET Application Architecture Guide，2nd Edition》，應(yīng)該可以從微軟的官網(wǎng)下載到，是微軟的模式與實(shí)踐小組的大作。Patterns & Practices在http://www.codeplex.com/上面有很多的好作品，其實(shí).NET平臺(tái)也有很好的開(kāi)源項(xiàng)目，也有很廣的選擇面，只是這些不像Java那么開(kāi)放，.NET的開(kāi)源是微軟主導(dǎo)的。

　　下載地址：patterns & practices: Application Architecture Guide 2.0

　　回到主題

　　軟件架構(gòu)經(jīng)常被描述成系統(tǒng)的組織或者是結(jié)構(gòu)，系統(tǒng)代表完成特殊功能，或者是一系列功能的組件集合。換句話說(shuō)，架構(gòu)也就是將組件組織起來(lái)，支持特定的功能。

　　下圖展示了常用的應(yīng)用架構(gòu)

　　除了組件分組，其它的就是組件之間的交互，以及不同的組件如何在一起工作。

　　關(guān)鍵的設(shè)計(jì)原則

　　在開(kāi)始設(shè)計(jì)之前，思考一下關(guān)鍵的原則，將會(huì)幫助你創(chuàng)建一個(gè)最小花費(fèi)、高可用性和擴(kuò)展性的架構(gòu)。

• 　　分離關(guān)注點(diǎn)，將應(yīng)用劃分為在功能上盡可能不重復(fù)的功能點(diǎn)。主要的參考因素就是最小化交互，高內(nèi)聚、低耦合。但是，錯(cuò)誤的分離功能邊界，可能會(huì)導(dǎo)致功能之間的高耦合性和復(fù)雜性，
• 　　職責(zé)單一，每一個(gè)組件或者是模塊應(yīng)該只有一個(gè)職責(zé)或者是功能，功能要內(nèi)聚。
• 　　最小知識(shí)原則，一個(gè)組件或者是對(duì)象不應(yīng)該知道其他組件或者對(duì)象的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)。
• 　　不要重復(fù)你自己，你只需要在一個(gè)地方描述目的。例如，特殊的功能只能在一個(gè)組件中實(shí)現(xiàn)，在其他的組件中不應(yīng)該有副本。
• 　　最小化預(yù)先設(shè)計(jì)，只設(shè)計(jì)必須的內(nèi)容。在一些情況，你可能需要預(yù)先設(shè)計(jì)一些內(nèi)容。另外一些情況，尤其對(duì)于敏捷開(kāi)發(fā)，你可以避免設(shè)計(jì)過(guò)度。如果你的應(yīng)用需求是不清晰的，最好不要做大量的預(yù)先設(shè)計(jì)。

　　當(dāng)設(shè)計(jì)一個(gè)應(yīng)用和系統(tǒng)的時(shí)候，軟件架構(gòu)的目的是通過(guò)將設(shè)計(jì)分離到不同的關(guān)注點(diǎn)，來(lái)最小化復(fù)雜性。例如，用戶接口UI，業(yè)務(wù)處理Business Process，數(shù)據(jù)訪問(wèn)Data Access就代表不同的關(guān)注點(diǎn)。在每個(gè)關(guān)注點(diǎn)內(nèi)部，你設(shè)計(jì)的組件應(yīng)該集中的內(nèi)部實(shí)現(xiàn)，不應(yīng)該和其他的組件混淆代碼。例如，UI處理組件不應(yīng)該包括直接訪問(wèn)數(shù)據(jù)源的代碼，相反，應(yīng)該使用業(yè)務(wù)組件或者是數(shù)據(jù)訪問(wèn)組建獲取數(shù)據(jù)。

　　但是，你還是要為你的應(yīng)用做一個(gè)投入|產(chǎn)出決定。在某些情況，你可能需要簡(jiǎn)化結(jié)構(gòu)。例如，UI直接綁定到一個(gè)結(jié)果集。通常，也要從業(yè)務(wù)的角度考慮功能的邊界。下面的這些高層次的原則將會(huì)幫助你從更廣的范圍上考慮影響設(shè)計(jì)、實(shí)現(xiàn)、部署、測(cè)試和維護(hù)系統(tǒng)的因素。

　　設(shè)計(jì)

• 　　在每一層保持設(shè)計(jì)模式的一致性。在一個(gè)邏輯層的內(nèi)部，組件的設(shè)計(jì)對(duì)于特殊的功能應(yīng)該保持一致性。
• 　　不要在應(yīng)用中復(fù)制功能。只能在一個(gè)組件中提供指定的功能，這個(gè)功能不能在其他組件中復(fù)制。這將會(huì)保持組件的內(nèi)聚性，而且如果功能需要修改的話，會(huì)變得很容易。
• 　　組合優(yōu)先于繼承。無(wú)論在什么地方，如果需要重用代碼的話，優(yōu)先使用組合而不是繼承，因?yàn)槔^承增加了父類和子類的依賴關(guān)系，限制了子類的重用，
• 　　為開(kāi)發(fā)建立代碼風(fēng)格和命名空間。建立統(tǒng)一的代碼風(fēng)格，使用和組織有關(guān)系的有意義的命名空間。
• 　　在開(kāi)發(fā)的過(guò)程中，使用QA來(lái)保證系統(tǒng)的質(zhì)量。在開(kāi)發(fā)的過(guò)程中，使用單元測(cè)試和其他QA技術(shù)，例如，依賴分析和靜態(tài)代碼分析。為組建和子系統(tǒng)定義清晰的行為和性能指標(biāo)，使用自動(dòng)化QA工具來(lái)保證不影響整個(gè)系統(tǒng)的質(zhì)量。

　　應(yīng)用分層

• 　　分離關(guān)注點(diǎn)。將應(yīng)用分離為不同的功能，這些功能保持盡可能小的重疊。主要的好處是一個(gè)功能可以最小化和其他功能的依賴關(guān)系。另外，如果一個(gè)功能失敗了，不會(huì)導(dǎo)致其他功能的失敗，對(duì)于其他功能來(lái)說(shuō)是獨(dú)立的。使得應(yīng)用更容易理解和設(shè)計(jì)，簡(jiǎn)化復(fù)雜系統(tǒng)的管理。
• 　　明確層之間是如何通信的。
• 　　使用抽象實(shí)現(xiàn)層之間的松散耦合。可以通過(guò)定義接口來(lái)實(shí)現(xiàn)。另外，還可以通過(guò)使用接口類型或者是基類定義常用的接口。
• 　　在同一層，不要混合不同類型的組件。例如，UI層不應(yīng)該包含業(yè)務(wù)處理組件，相反，應(yīng)該包含處理用戶輸入和處理用戶請(qǐng)求的組件。
• 　　在層和組件內(nèi)部保持?jǐn)?shù)據(jù)格式的一致性。混亂的數(shù)據(jù)格式，將會(huì)導(dǎo)致系統(tǒng)更難實(shí)現(xiàn)、擴(kuò)展和維護(hù)。

　　組件、模塊和功能

• 　　一個(gè)組件和對(duì)象不應(yīng)該依賴于其他組件的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)。
• 　　組件的功能不要超出范圍。例如，UI處理組件不應(yīng)該包含數(shù)據(jù)訪問(wèn)代碼，或者是試圖提供其他的功能。
• 　　理解組件之間是如何通信的。這需要理解應(yīng)用一定要支持的部署方案。你一定要決定是否所有的組件都運(yùn)行在同一個(gè)進(jìn)程中？是否一定要支持跨越物理或者是進(jìn)程邊界的通信？還是實(shí)現(xiàn)消息為基礎(chǔ)的接口？
• 　　為組件定義一個(gè)清晰的職責(zé)。

　　你還要考慮下面的這些橫向的關(guān)注點(diǎn)：

• 　　日志
• 　　認(rèn)證
• 　　授權(quán)
• 　　異常管理
• 　　通信。選擇合適的協(xié)議，最小化網(wǎng)絡(luò)的通信量，在網(wǎng)絡(luò)上保護(hù)傳遞的敏感信息。
• 　　緩存。為了提高系統(tǒng)的性能和響應(yīng)速度，需要確定什么應(yīng)該緩存？緩存在哪里？設(shè)計(jì)緩存的時(shí)候，要考慮到web服務(wù)器場(chǎng)和應(yīng)用服務(wù)器場(chǎng)的問(wèn)題。

　　未完待續(xù)。。。。。。。。。

　　p19

it知識(shí)庫(kù)：.NET 應(yīng)用架構(gòu)指導(dǎo) V2 學(xué)習(xí)筆記（一） 軟件架構(gòu)的關(guān)鍵原則，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。