前幾天參加了中科院計(jì)算所培訓(xùn)中心謝老師的高級(jí)系統(tǒng)架構(gòu)師培訓(xùn)課程，將其中的一些點(diǎn)做了下記錄：
系統(tǒng)架構(gòu)師的工作是復(fù)雜設(shè)計(jì)總體解決方案以及領(lǐng)域?qū)ο蟮倪壿嫼臀锢聿季?這是一項(xiàng)在復(fù)雜環(huán)境中高風(fēng)險(xiǎn)、高影響力的活動(dòng)。
1、軟件架構(gòu)的定義：軟件架構(gòu)(Software Architecture)也稱之為軟件體系結(jié)構(gòu)，它是一組有關(guān)如下要素的重要決策：軟件系統(tǒng)的組織，構(gòu)成系統(tǒng)的結(jié)構(gòu)化元素，接口和它們相互協(xié)作的行為的選擇，結(jié)構(gòu)化元素和行為元素組合成粒度更大的子系統(tǒng)方式的選擇，以及指導(dǎo)這一組織(元素及其接口、協(xié)作和組合方式)的架構(gòu)風(fēng)格的選擇。換句話說(shuō)，軟件架構(gòu)實(shí)際上是對(duì)系統(tǒng)整體結(jié)構(gòu)設(shè)計(jì)的刻劃，系統(tǒng)架構(gòu)師是做全局的、整體的把握工作。架構(gòu)的組成與決策是架構(gòu)設(shè)計(jì)的兩個(gè)基本概念。架構(gòu)=>藍(lán)圖+規(guī)則+解決方案
軟件架構(gòu)是一個(gè)認(rèn)識(shí)事物的過(guò)程：原型、發(fā)現(xiàn)、改進(jìn)、再發(fā)現(xiàn)、再改進(jìn)，這是軟件開(kāi)發(fā)的必由螺旋。
2、架構(gòu)師成長(zhǎng)路線圖：系統(tǒng)架構(gòu)師已經(jīng)不僅僅是技術(shù)精湛的技術(shù)專家，他需要與業(yè)務(wù)團(tuán)隊(duì)緊密合作，并且精通市場(chǎng)、業(yè)務(wù)與管理。從上升趨勢(shì)來(lái)說(shuō)，可以有三個(gè)層面的路線圖：第一個(gè)層面，要關(guān)注系統(tǒng)思考。在這個(gè)層面，重要的不僅僅是掌握設(shè)計(jì)的知識(shí)點(diǎn)，而是更重視分析能力、創(chuàng)新思維能力的提升，需要更廣闊的思路，這方面的空間相當(dāng)非常大。這是第一層面的能力基礎(chǔ)。第二個(gè)層面，要關(guān)注總結(jié)和指導(dǎo)，思維空間要轉(zhuǎn)向群體。如何把已有的經(jīng)驗(yàn)總結(jié)出來(lái)，并讓這種智力資產(chǎn)真正發(fā)揮作用？成為架構(gòu)師上升第二層面的能力基礎(chǔ)。第三個(gè)層面，要提升自身的全面修養(yǎng)。我們必須引發(fā)自己思維方式的變革，要培養(yǎng)組織力、領(lǐng)導(dǎo)力、創(chuàng)新力以及擁有激情，這是架構(gòu)師上升第三層面的能力基礎(chǔ)。
要看到自身的弱點(diǎn)，思路要寬，多思考
架構(gòu)師并不是一個(gè)普通的技術(shù)人員，他對(duì)設(shè)計(jì)站的角度更高，需要的知識(shí)和能力結(jié)構(gòu)更復(fù)雜，他需要具有其他人所沒(méi)有的思想、眼光和感知世界的方法，必須突破已有的思維模式和行為模式，突破長(zhǎng)期束縛自己的思維瓶頸，才可能達(dá)到自己從未達(dá)到過(guò)的高度。
架構(gòu)師要養(yǎng)成每項(xiàng)工作都記錄并分析的好習(xí)慣，以形成更扎實(shí)的工作風(fēng)格。在每個(gè)項(xiàng)目完成都需要進(jìn)行總結(jié)。
3、架構(gòu)師要保持自己的競(jìng)爭(zhēng)力：架構(gòu)師必須關(guān)注今天的IT技術(shù)、商業(yè)模式變革以及由此引發(fā)的軟件產(chǎn)業(yè)變革的重大趨勢(shì)，勤于思考并迎接新的挑戰(zhàn)。一個(gè)人最核心的競(jìng)爭(zhēng)優(yōu)勢(shì)是學(xué)習(xí)能力。架構(gòu)師作為技術(shù)層面資深的一群，為了保持競(jìng)爭(zhēng)力需要注意以下幾個(gè)問(wèn)題：(1)、保持激情：關(guān)鍵是信念。激情源自于信念，有了信念才會(huì)主動(dòng)挑戰(zhàn)自我，迎接挑戰(zhàn)才會(huì)有激情，有了激情工作才會(huì)更有意思。(2)、創(chuàng)新思考：在工作中多嘗試一些新方法，是維持自我能力的重要手段。(3)、逆向思維：逆向思維指的是使用與正常思路相反的思維方式去分析同一個(gè)問(wèn)題，使思路多樣化。逆向思維能夠幫助人們沖破傳統(tǒng)思維的束縛，克服慣性思維方式。從反方向考慮問(wèn)題往往會(huì)取得出人意料的結(jié)果。
4、架構(gòu)師要關(guān)注軟件的新趨勢(shì)：目前傳統(tǒng)軟件危機(jī)暴露出的問(wèn)題還未真正解決，新的挑戰(zhàn)卻已擺在眼前。在人們不斷思考面臨的挑戰(zhàn)以及對(duì)策中，形成了一些新的趨勢(shì)，包括：(1)、軟件質(zhì)量以服務(wù)質(zhì)量形式展現(xiàn)，對(duì)質(zhì)量的投資可獲得更高的投資回報(bào)。(2)、軟件過(guò)程擴(kuò)展到用戶，希望更多的用戶深入?yún)⑴c到軟件全生命周期。(3)、功能至上遠(yuǎn)遠(yuǎn)不夠，用戶體驗(yàn)得到空前重視。(4)、系統(tǒng)集成模式面臨變革，軟件、服務(wù)、終端、IT基礎(chǔ)設(shè)施將形成更緊密的價(jià)值體系。(5)、研發(fā)要更多關(guān)注非功能性需求，如安全性質(zhì)量、性能、可靠性、可擴(kuò)充性、可伸縮性、可用性等，從而不斷提高軟件的價(jià)值。
知識(shí)就是力量==>信息就是力量
架構(gòu)并不完全是概要設(shè)計(jì)。概要設(shè)計(jì)還是停留在圖紙上，而架構(gòu)必須證明這個(gè)技術(shù)路線可行，并且能夠證明大多數(shù)質(zhì)量風(fēng)險(xiǎn)已經(jīng)得到了解決。
5、所謂設(shè)計(jì)就是解決問(wèn)題的過(guò)程：軟件設(shè)計(jì)是一種思維活動(dòng)，設(shè)計(jì)的魅力在于破解難題，通過(guò)直面問(wèn)題的挑戰(zhàn)，以及對(duì)相應(yīng)解決方案的仔細(xì)推敲，才可能設(shè)計(jì)出真正有靈性的產(chǎn)品。(1)、設(shè)計(jì)不具普遍性：軟件設(shè)計(jì)很少具有普通性，不同的目標(biāo)需要不同的設(shè)計(jì)來(lái)支持。(2)、做出權(quán)衡：所謂軟件設(shè)計(jì)，本質(zhì)上就是在質(zhì)量、成本、時(shí)間以及其它各種因素之間做出權(quán)衡。(3)、記錄設(shè)計(jì)的理由(設(shè)計(jì)文檔)。
多關(guān)注各種方面的架構(gòu)設(shè)計(jì)
6、質(zhì)量屬性決定了架構(gòu)風(fēng)格：一種架構(gòu)的風(fēng)格，很大程度上與設(shè)計(jì)者如何滿足質(zhì)量要求的對(duì)策有關(guān)。需求的功能和非功能兩方面都可能有質(zhì)量要求。具體歸納如下：(1)、與功能性有關(guān)的質(zhì)量屬性主要包括：A、正確性：是指軟件按照需求正確執(zhí)行任務(wù)的能力。B、健壯性：指的是在異常情況下，軟件能夠正常運(yùn)行的能力。正確性與健壯性的區(qū)別在于，前者是在功能需求之內(nèi)描述問(wèn)題，后者是在功能需求之外描述問(wèn)題。健壯性一般有兩層含義：首先是容錯(cuò)能力，其次是恢復(fù)能力。容錯(cuò)指的是發(fā)生異常情況不出錯(cuò)誤的能力，而恢復(fù)指的是軟件發(fā)生錯(cuò)誤以后能恢復(fù)到?jīng)]有發(fā)生錯(cuò)誤錢(qián)的狀態(tài)的能力。C、可靠性：是一個(gè)與時(shí)間相關(guān)的屬性，指的是在一定的環(huán)境下，在一定的時(shí)間段，系統(tǒng)不出現(xiàn)故障的概率。通常用平均無(wú)故障時(shí)間來(lái)衡量。(2)、與非功能性有關(guān)的質(zhì)量屬性主要包括：A、性能：是指軟件的“時(shí)間-空間”效率，而不僅僅是指軟件運(yùn)行速度。換句話說(shuō)是速度要快而占用資源要少。性能=速度/資源。B、易用性：指的是用戶使用軟件的容易程度。C、清晰性：意味著工作成果易讀、易理解。D、安全性：它的目的是系統(tǒng)應(yīng)該具備防止非法入侵的能力，這既屬于技術(shù)問(wèn)題也屬于管理問(wèn)題。E、可擴(kuò)展性：這反映軟件適應(yīng)“變化”的能力，包括需求、設(shè)計(jì)的變化、算法的改進(jìn)和變化。F、可移植性：指的是軟件不經(jīng)修改(或者稍加修改)就可以在不同軟硬件環(huán)境中使用的能力。
7、抵制前期進(jìn)行龐大設(shè)計(jì)的誘惑：(1)、架構(gòu)應(yīng)該具備易演化特征；(2)、項(xiàng)目開(kāi)發(fā)周期不要超過(guò)6個(gè)月；(3)、分而治之：抓住真正的需求、分而治之(把大項(xiàng)目分成小項(xiàng)目)、設(shè)置優(yōu)先級(jí)、盡快交付；(4)、增量式開(kāi)發(fā)與交付：如果前期需求比較清楚，可以把一個(gè)大項(xiàng)目分成若干相對(duì)獨(dú)立能夠持續(xù)交付的部分，這樣就可以把大問(wèn)題分成若干小問(wèn)題；(5)、迭代式開(kāi)發(fā)與交付：如果前期需求不是太清楚，項(xiàng)目帶有強(qiáng)烈的創(chuàng)新成分，可以使用具有強(qiáng)迭代的逐步求精的模型。
8、重構(gòu)：在不影響整體外部行為的前提下，不斷地對(duì)軟件進(jìn)行細(xì)微的設(shè)計(jì)改進(jìn)，這種漸進(jìn)式的實(shí)踐叫做重構(gòu)。通過(guò)重構(gòu)不僅能夠降低維護(hù)成本，而且也為我們提供了改進(jìn)代碼質(zhì)量的通用標(biāo)準(zhǔn)，并使我們能迅速添加新功能。從本質(zhì)上說(shuō)，重構(gòu)根本上就是一個(gè)態(tài)度問(wèn)題，而不全是技術(shù)問(wèn)題。
在集中精力完成了代碼邏輯以后，就需要集中精力做第二件事情，那就是重構(gòu)。在對(duì)代碼進(jìn)行重構(gòu)時(shí)，我們不會(huì)增加新功能，甚至也不會(huì)去修復(fù)bug。相反，我們會(huì)通過(guò)將代碼變得更易于理解來(lái)提升代碼的可讀性。
重構(gòu)要堅(jiān)持不懈：(1)重構(gòu)可以加快進(jìn)度；(2)、重構(gòu)應(yīng)該是小步驟地進(jìn)行；(3)、技術(shù)債務(wù)積累越多，重構(gòu)的難度就越大。
9、對(duì)結(jié)構(gòu)進(jìn)行優(yōu)化的基本原則：在完成了功能邏輯之后，除了代碼重構(gòu)以外，很多情況下還需要重新審視一下軟件結(jié)構(gòu)，對(duì)結(jié)構(gòu)進(jìn)行重構(gòu)。良好的結(jié)構(gòu)設(shè)計(jì)需要遵循一些原則，而原則本身就是經(jīng)驗(yàn)的總結(jié)。依據(jù)這些原則，我們就可以在設(shè)計(jì)中有良好的設(shè)計(jì)指向。如需求不變則不需結(jié)構(gòu)。
結(jié)構(gòu)的4條設(shè)計(jì)原則：(1)單一職責(zé)原則(SRP)：也被稱之為內(nèi)聚性原則；SRP原則的描述為：就一個(gè)類而言，應(yīng)該僅有一個(gè)引起它變化的原因；(2)、開(kāi)放--封閉原則(OCP)：OCP的關(guān)鍵是依賴于抽象。OCP原則的目的，是要求我們?cè)O(shè)計(jì)的軟件實(shí)體(類、組件、函數(shù)等等)應(yīng)該是可以擴(kuò)展的，但是不可修改的。A、對(duì)于擴(kuò)展是開(kāi)放的：這意味著組件的行為是可以擴(kuò)展的，當(dāng)應(yīng)用的需求改變時(shí)，我們可以對(duì)組件進(jìn)行擴(kuò)展，使其具有滿足那些改變的新行為。換句話說(shuō)我們可以改變組件的功能。B、對(duì)于更改是封閉的：對(duì)組件行為進(jìn)行擴(kuò)展時(shí)，不必改動(dòng)組件的源代碼，無(wú)論是動(dòng)態(tài)鏈接庫(kù)、DLL或者是Java的jar文件都無(wú)需改動(dòng)。(3)、依賴倒置原則(DIP)：使用傳統(tǒng)的結(jié)構(gòu)化設(shè)計(jì)所創(chuàng)建出來(lái)的依賴關(guān)系結(jié)構(gòu)，策略是依賴于細(xì)節(jié)的，這是糟糕的，因?yàn)檫@樣會(huì)使策略受到細(xì)節(jié)改變的影響。面向?qū)ο蟮某绦蛟O(shè)計(jì)倒置了依賴關(guān)系結(jié)構(gòu)，使得細(xì)節(jié)和策略都依賴于抽象，并且常常是客戶擁有服務(wù)接口。事實(shí)上，這種依賴關(guān)系的倒置正是好的面向?qū)ο笤O(shè)計(jì)的標(biāo)志所在。DIP的原則是：A、高層組件不應(yīng)該依賴于低層組件。二者都應(yīng)該依賴于抽象；B、抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象。(4)、接口隔離原則(ISP)：這個(gè)原則用來(lái)處理“胖(fat)”接口所具有的缺點(diǎn)。類的“胖”(不內(nèi)聚)接口可以分解成多組方法。每一組方法都服務(wù)于一組不同的客戶程序。這樣，一些客戶程序可以使用一組成員函數(shù)，而其它客戶程序可以使用其它組的成員函數(shù)。實(shí)際中當(dāng)然也存在有一些對(duì)象，它們確實(shí)不需要內(nèi)聚的接口，但是ISP建議客戶程序不應(yīng)該看到它們作為單一的類存在。相反，客戶程序看到的應(yīng)該是多個(gè)具有內(nèi)聚接口的抽象基類。
10、關(guān)注變化、關(guān)注特征：擁抱著變化而設(shè)計(jì)。讓變化成為一個(gè)重要的設(shè)計(jì)要素，需求總是會(huì)發(fā)生變化。面向?qū)ο笫莻€(gè)思維方式?；诮涌谶M(jìn)行設(shè)計(jì)。
軟件復(fù)用(SoftwareReuse)：是將已有軟件的各種有關(guān)知識(shí)用于建立新的軟件，以縮減軟件開(kāi)發(fā)和維護(hù)的花費(fèi)。軟件復(fù)用是提高軟件生產(chǎn)力和質(zhì)量的一種重要技術(shù)。早期的軟件復(fù)用主要是代碼級(jí)復(fù)用，被復(fù)用的知識(shí)專指程序，后來(lái)擴(kuò)大到包括領(lǐng)域知識(shí)、開(kāi)發(fā)經(jīng)驗(yàn)、設(shè)計(jì)決定、體系結(jié)構(gòu)、需求、設(shè)計(jì)、代碼和文檔等一切有關(guān)方面。
軟件重用，是指在兩次或多次不同的軟件開(kāi)發(fā)過(guò)程中重復(fù)使用相同或相似軟件元素的過(guò)程。軟件元素包括程序代碼、測(cè)試用例、設(shè)計(jì)文檔、設(shè)計(jì)過(guò)程、需要分析文檔甚至領(lǐng)域知識(shí)。通常，可重用的元素也稱作軟構(gòu)件，可重用的軟構(gòu)件越大，重用的粒度越大。
11、面向服務(wù)的架構(gòu)(Service-OrientedArchitecture, SOA)：面向服務(wù)的架構(gòu)成功的要點(diǎn)是服務(wù)識(shí)別。服務(wù)識(shí)別的基本過(guò)程：(1)、了解項(xiàng)目的性質(zhì)；(2)、業(yè)務(wù)牽頭，一定不是技術(shù)牽頭；(3)、明確產(chǎn)品的戰(zhàn)略目標(biāo)；(4)、研究企業(yè)業(yè)務(wù)流程；(5)、重用行業(yè)制品；(6)、建立契約基線；(7)、完善服務(wù)屬性等級(jí)矩陣(ARMS)；(8)、使用業(yè)務(wù)敏捷場(chǎng)景仿真(BASS)進(jìn)行測(cè)試；(9)、擁抱變更。
12、架構(gòu)與框架的區(qū)別：框架是一個(gè)軟件，但架構(gòu)不是軟件，而是關(guān)于軟件如何設(shè)計(jì)的重要決策。但是在引入軟件框架以后，軟件架構(gòu)決策往往會(huì)體現(xiàn)在框架設(shè)計(jì)之中。不論是架構(gòu)技術(shù)還是框架技術(shù)，都是為了解決軟件日益復(fù)雜所帶來(lái)的困難，而采取的“分而治之”的結(jié)果。架構(gòu)的思維是先大局后局部，這是一種問(wèn)題在抽象層面地解決方案，首先考慮大局而忽略細(xì)節(jié)?？蚣艿乃季S是先通用后專用，這是一種半成品，還需要通過(guò)后期的定制才能成為具體的軟件。
框架和架構(gòu)的關(guān)系可以總結(jié)為兩個(gè)方面：(1)、為了盡早驗(yàn)證架構(gòu)設(shè)計(jì)，或者出于支持產(chǎn)品線開(kāi)發(fā)的目的，可以把通用機(jī)制甚至整個(gè)架構(gòu)以框架方式實(shí)現(xiàn)；(2)、企業(yè)可能存在大量可重用框架，這些框架可能已經(jīng)實(shí)現(xiàn)了架構(gòu)所需的重要機(jī)制，或者對(duì)某個(gè)子系統(tǒng)提供了可擴(kuò)展的半成品，最終軟件架構(gòu)可以借助這些框架來(lái)構(gòu)造。
框架設(shè)計(jì)最重要的部分，其實(shí)并不在于采用何種技術(shù)方案來(lái)實(shí)現(xiàn)，而是對(duì)已經(jīng)存在的業(yè)務(wù)過(guò)程進(jìn)行深入思考，尋找它們的共性，探究其中的規(guī)律，建立恰當(dāng)?shù)哪Ｊ?，然后選擇恰當(dāng)?shù)募夹g(shù)實(shí)現(xiàn)方案。
帶團(tuán)隊(duì)關(guān)鍵因素：決心、手段(方法)、激情、信心，技術(shù)不是關(guān)鍵因素。
13、把經(jīng)驗(yàn)歸納總結(jié)成理論：總結(jié)是兩方面的，(1)總結(jié)過(guò)程：歸納出良好設(shè)計(jì)必須遵循的步驟，以及每一步驟的目標(biāo)、解決什么問(wèn)題、應(yīng)該有什么樣的思考點(diǎn)和思考方向。(2)總結(jié)模式(設(shè)計(jì)模式)：模式是一種實(shí)踐經(jīng)驗(yàn)的總結(jié)，通過(guò)總結(jié)每個(gè)思考點(diǎn)的各種解決方案，并且和過(guò)程的節(jié)點(diǎn)裝配在一起，形成能夠指導(dǎo)他人的模式語(yǔ)言。
目前大約有110多種設(shè)計(jì)模式，模式不是教條，模式僅僅是經(jīng)驗(yàn)的總結(jié)
模式是一種經(jīng)過(guò)命名的對(duì)于解決方案的格式化經(jīng)驗(yàn)總結(jié)，它能有效地幫助我們歸納和使用經(jīng)驗(yàn)。
14、在軟件設(shè)計(jì)中，宏觀上看自上而下大致上可以分成三個(gè)大的過(guò)程域，它包括：頂層架構(gòu)設(shè)計(jì)過(guò)程域；領(lǐng)域?qū)ο笤O(shè)計(jì)過(guò)程域；資源應(yīng)用設(shè)計(jì)過(guò)程域，圖1。
圖 1
頂層架構(gòu)設(shè)計(jì)過(guò)程域的目標(biāo)是：建立一個(gè)系統(tǒng)的概念性架構(gòu)，為系統(tǒng)描繪一個(gè)初始的輪廓，并且對(duì)涉及全局的問(wèn)題進(jìn)行決策。
領(lǐng)域?qū)ο笤O(shè)計(jì)過(guò)程域的目標(biāo)是：根據(jù)細(xì)化的領(lǐng)域?qū)ο竽Ｐ?，在?xì)節(jié)層面對(duì)每一個(gè)領(lǐng)域?qū)ο筮M(jìn)行刻畫(huà)，并且對(duì)于這些細(xì)節(jié)層面的技術(shù)問(wèn)題進(jìn)行決策。
資源應(yīng)用設(shè)計(jì)過(guò)程域的目標(biāo)是：在宏觀和微觀兩個(gè)層面，對(duì)于涉及內(nèi)存、對(duì)象、數(shù)據(jù)等方面的方案和問(wèn)題進(jìn)行決策。
為了進(jìn)一步的細(xì)化，在每個(gè)過(guò)程域內(nèi)部，又可以包括一系列的過(guò)程，(用于解決一個(gè)特定的主題和問(wèn)題，被稱之為過(guò)程)。這樣一來(lái)，宏觀設(shè)計(jì)過(guò)程就可以分成11組內(nèi)聚的過(guò)程(問(wèn)題域)。要注意到盡管過(guò)程的描述是清晰分離的，但整個(gè)軟件的設(shè)計(jì)并不僅僅是自上而下逐步求精的過(guò)程，而是相互影響、互相支持、在設(shè)計(jì)過(guò)程中不斷優(yōu)化的不斷反饋過(guò)程，圖2。
圖 2
設(shè)計(jì)模式匯總：
Domain Model：定義了一個(gè)應(yīng)用領(lǐng)域結(jié)構(gòu)和工作流的精確模型，其中還包括它們的變化。
Layers：解決系統(tǒng)合理分層的問(wèn)題。
Model-View-Controller：解決對(duì)用戶界面變化的支持問(wèn)題。支持某一特定用戶界面的變化。
Presentation-Abstraction-Control：解決相同業(yè)務(wù)具有多種表現(xiàn)形式問(wèn)題。
Microkernel：解決業(yè)務(wù)具有多種不同業(yè)務(wù)方法的問(wèn)題。
Refelection：解決需要?jiǎng)討B(tài)改變軟件系統(tǒng)結(jié)構(gòu)和行為的問(wèn)題。
Pipes and Filters：解決算法的結(jié)構(gòu)化并可以重新構(gòu)建的問(wèn)題。
Shared Repository：適用于網(wǎng)絡(luò)管理和控制系統(tǒng)領(lǐng)域。
Blackboard：解決運(yùn)行中智能化改進(jìn)處理方法的問(wèn)題。
Domain Object：表現(xiàn)為已經(jīng)將自我完備的連貫功能和基礎(chǔ)性責(zé)任封裝成定義良好的實(shí)體，通過(guò)一個(gè)或多個(gè)”顯示接口”提供功能，并隱藏內(nèi)部結(jié)構(gòu)和實(shí)現(xiàn)。
Messaging：由一系列相互連接的MessageChannel和Message Router管理著跨網(wǎng)絡(luò)的不同服務(wù)間的消息交換。
Message Channel：解決如何把彼此協(xié)作的客戶端和服務(wù)連接起來(lái)的問(wèn)題。
Message Router：解決如何根據(jù)條件接受”信道”消息的問(wèn)題。
Message Translator：解決如何轉(zhuǎn)換消息格式的問(wèn)題。
Message Endpoint：解決把數(shù)據(jù)轉(zhuǎn)換為消息中間件能夠理解的形式的問(wèn)題。
Publisher-Subscriber：為了在應(yīng)用中更好的把彼此關(guān)注的事件通知給其它領(lǐng)域?qū)ο蟆?/p>
Broker：通過(guò)一個(gè)代理管理器管理領(lǐng)域?qū)ο箝g遠(yuǎn)程互操作的各個(gè)關(guān)鍵方面。
Client Proxy：解決客戶端應(yīng)用與網(wǎng)絡(luò)基礎(chǔ)設(shè)施相互屏蔽的問(wèn)題。
Requestor：解決應(yīng)用代碼被基礎(chǔ)設(shè)施的代碼污染而影響可移植性的問(wèn)題。
Invoker：解決服務(wù)代碼被基礎(chǔ)設(shè)施的代碼污染而影響可移植性的問(wèn)題。
Client Request Handler：解決客戶端應(yīng)用與通信相互影響的問(wèn)題，它封裝了客戶端在統(tǒng)一的接口背后進(jìn)行的進(jìn)程間通信的細(xì)節(jié)。
Server Request Handler：解決服務(wù)端應(yīng)用與通信相互影響的問(wèn)題，封裝了服務(wù)器端在統(tǒng)一的接口背后進(jìn)行的進(jìn)程間通信的細(xì)節(jié)。
Reactor：解決在應(yīng)用中避免使用多線程的問(wèn)題。
Proactor：解決在多線程的背景下出現(xiàn)性能問(wèn)題的缺陷。
Acceptor-Connector：把事件初始化與具體處理方法分離，從而提高可維護(hù)性。
Asynchronous Completion Token：解決異步到達(dá)的事件仍然能按一定順序處理的問(wèn)題。
Explicit Interface：解決如何正確設(shè)計(jì)接口的問(wèn)題。
Extension Interface：隨著時(shí)間的推移，組件的接口是會(huì)膨脹的，一個(gè)胖的接口將更脆弱。解決防止”胖”接口并分離接口。
Introspective Interface：解決公開(kāi)內(nèi)部信息接口的問(wèn)題。
Dynamic Invocation Interface：解決同一個(gè)接口允許客戶端調(diào)用多種方法的問(wèn)題。
Proxy：解決在同一個(gè)接口下通過(guò)代理屏蔽某些實(shí)現(xiàn)的問(wèn)題。
Business Delegate：由本地業(yè)務(wù)代表來(lái)完成所有網(wǎng)絡(luò)任務(wù)，分離了應(yīng)用和網(wǎng)絡(luò)處理的業(yè)務(wù)，減少了開(kāi)發(fā)難度、提高了可理解性和可維護(hù)性。
Facade：解決屏蔽子系統(tǒng)的變化輻射到高層應(yīng)用的問(wèn)題。
Combined Method：解決多種相互關(guān)聯(lián)的方法不合理的分布的問(wèn)題。
Iterator：解決分布式元素能夠方便迭代的問(wèn)題。
Enumeration Method：解決減少外部迭代方式多次對(duì)聚合中的元素進(jìn)行獨(dú)立訪問(wèn)開(kāi)銷的問(wèn)題。
Batch Method：解決多次訪問(wèn)加大網(wǎng)絡(luò)開(kāi)銷的問(wèn)題。
Encapsulated Implementation：解決對(duì)象劃分的基本原則和方法問(wèn)題。
Composite：建立一種結(jié)構(gòu)靈活的樹(shù)狀結(jié)構(gòu)對(duì)象組織形式，形成“整體/部分”層級(jí)結(jié)構(gòu)。
Half-Object plus Protocol：通過(guò)在分布式系統(tǒng)中合理布局對(duì)象，以減少不合理的網(wǎng)絡(luò)流量和服務(wù)器壓力。
Replicated Component Group：解決分布式系統(tǒng)容錯(cuò)的問(wèn)題，復(fù)制的組件實(shí)現(xiàn)位于不同的網(wǎng)絡(luò)節(jié)點(diǎn)，并組成一個(gè)組件組。
Half-Sync/Half-Async：對(duì)并發(fā)系統(tǒng)中的異步和同步服務(wù)處理解耦合以簡(jiǎn)化編程，但又不會(huì)過(guò)度地影響性能。
Leader/Followers：解決大批量小處理的環(huán)境下減少并發(fā)線程應(yīng)用的問(wèn)題。
Active Object：為了減少服務(wù)器并發(fā)線程應(yīng)用。
Monitor Object：解決并發(fā)業(yè)務(wù)相互協(xié)調(diào)的問(wèn)題。
Guarded Suspension：在并發(fā)性程序中，當(dāng)某個(gè)線程對(duì)一個(gè)資源進(jìn)行訪問(wèn)的時(shí)候，首先需要判斷這個(gè)資源的警戒條件是否成立。
Future：并發(fā)調(diào)用的服務(wù)可能需要向客戶端返回結(jié)果。
Thread-Safe Interface：避免自死鎖和加鎖開(kāi)銷。
Strategized Locking：在創(chuàng)建或聲明時(shí)，為組件配置適當(dāng)類型的鎖實(shí)例。使用該鎖實(shí)例來(lái)保護(hù)組件中的所有臨界區(qū)。
Scoped Locking：解決復(fù)雜繁瑣代碼中的疏忽發(fā)生漏釋放造成死鎖的問(wèn)題。
Thread-Specific Storage：解決頻繁使用對(duì)象造成反復(fù)加鎖解鎖造成的性能問(wèn)題。
Copied Value：解決共享的值對(duì)象必須鎖定帶來(lái)的性能問(wèn)題。
Immutable Value：解決共享的值對(duì)象必須鎖定帶來(lái)的性能問(wèn)題。
Observer：定義一個(gè)特定的更新接口，通過(guò)該接口，Observer獲得Subject狀態(tài)變更的通知。
Double Dispatch：根據(jù)運(yùn)行時(shí)多個(gè)對(duì)象的類型確定方法調(diào)用的過(guò)程。
Mediator：封裝集合中所有對(duì)象的聚合協(xié)作行為，從而將這些對(duì)象解耦合。
Command：為這些對(duì)象定義一個(gè)通用接口，來(lái)執(zhí)行它們所代表的請(qǐng)求。
Memento：解決在不破壞封裝性的前提下正確存儲(chǔ)和讀取分布式對(duì)象狀態(tài)的問(wèn)題。
Context Object：解決在松耦合系統(tǒng)中共享與程序執(zhí)行上下文相關(guān)的通用信息的問(wèn)題。
Data Transfer Object：解決細(xì)粒度調(diào)用多次訪問(wèn)遠(yuǎn)程對(duì)象單個(gè)屬性所帶來(lái)的巨大開(kāi)銷問(wèn)題。
Message：解決網(wǎng)絡(luò)協(xié)議只支持比特流這種最簡(jiǎn)單的數(shù)據(jù)傳輸形式，并不能識(shí)別服務(wù)調(diào)用和數(shù)據(jù)類型的問(wèn)題。
Bridge：解決在下層穩(wěn)定的業(yè)務(wù)中嵌入上次變化部分的問(wèn)題。
Object Adapter：解決接口變化導(dǎo)致的不兼容問(wèn)題。
Chain of Responsibility：解決對(duì)象結(jié)構(gòu)和請(qǐng)求分發(fā)邏輯上的變化影響到客戶端的問(wèn)題。
Interceptor：解決構(gòu)建一個(gè)可插拔的框架變化模型的問(wèn)題。
Visitor：解決將服務(wù)的實(shí)現(xiàn)分散在定義對(duì)象結(jié)構(gòu)的各個(gè)類中難以進(jìn)行集中處理的問(wèn)題。
Decorator：解決在穩(wěn)定的核心功能外圍添加擴(kuò)展的問(wèn)題。
Template Method：解決在下層穩(wěn)定的業(yè)務(wù)中嵌入上次變化部分的問(wèn)題。
Strategy：解決在一個(gè)或多個(gè)方法中根據(jù)不同的情況執(zhí)行不同行為的問(wèn)題。
Wrapper Facade：主要解決應(yīng)用代碼使用底層API所提供的服務(wù)但代碼難以理解的問(wèn)題，需要對(duì)底層API進(jìn)行面向?qū)ο蟮姆庋b，通過(guò)提供一個(gè)簡(jiǎn)潔的、健壯的、可移植的、內(nèi)聚的面向?qū)ο蟮慕涌?，?lái)達(dá)到封裝函數(shù)和數(shù)據(jù)的目的。
Declarative Component Configuration：建立需要安裝各類插件的宿主基礎(chǔ)設(shè)施，使其能夠正確管理運(yùn)行時(shí)環(huán)境，可靠運(yùn)用系統(tǒng)資源和服務(wù)的問(wèn)題。
Container：解決領(lǐng)域?qū)ο笾苯犹幚砥脚_(tái)環(huán)境造成它與平臺(tái)緊密耦合并增加實(shí)現(xiàn)的復(fù)雜性的問(wèn)題。
Component Configurator：解決在組件生命周期后期和升級(jí)時(shí)重新配置組件的問(wèn)題。
Object Manager：解決客戶端依賴對(duì)象管理增加應(yīng)用內(nèi)部的耦合度和復(fù)雜度的問(wèn)題。
Virtual Proxy：解決從一個(gè)巨大數(shù)據(jù)庫(kù)中把所有的對(duì)象全部加載進(jìn)來(lái)消耗大量資源的問(wèn)題。
Resource Pool：解決獲取和釋放資源(網(wǎng)絡(luò)連接、線程或者內(nèi)容)引入一定的性能開(kāi)銷問(wèn)題。
Resource Cache：解決幾個(gè)有限的資源用戶頻繁創(chuàng)建和釋放資源帶來(lái)不必要的性能開(kāi)銷問(wèn)題。
Automated Garbage Collection：解決不能及時(shí)將不再使用的內(nèi)存收回可能耗盡內(nèi)存的問(wèn)題。
Counting Handles：解決確保在堆上創(chuàng)建的共享對(duì)象能夠可靠地、安全地、及時(shí)地回收的問(wèn)題。
Abstract Factory：解決一批對(duì)象用統(tǒng)一的方法進(jìn)行創(chuàng)建和銷毀的問(wèn)題。
Builder：解決對(duì)需要多步完成對(duì)象的創(chuàng)建時(shí)，簡(jiǎn)化創(chuàng)建過(guò)程的復(fù)雜性和多樣性問(wèn)題。
Factory Method：解決直接創(chuàng)建對(duì)象可能導(dǎo)致代碼的混亂并影響調(diào)用端代碼的獨(dú)立性問(wèn)題。
Disposal Method：解決銷毀對(duì)象時(shí)可能需要多個(gè)步驟而引人過(guò)度的耦合問(wèn)題。
Database Access Layer：它通過(guò)在兩種之間引人一個(gè)映射層將面向?qū)ο髴?yīng)用設(shè)計(jì)同關(guān)系型數(shù)據(jù)庫(kù)分離開(kāi)。
Data Mapper：解決數(shù)據(jù)模型和持久化的表結(jié)構(gòu)之間完全的解耦合的問(wèn)題。
Row Data Gateway：解決更細(xì)致的數(shù)據(jù)模型和持久化的表結(jié)構(gòu)之間完全解耦的問(wèn)題。
Table Data Gateway：解決更細(xì)致的數(shù)據(jù)模型和持久化的表結(jié)構(gòu)之間完全解耦的問(wèn)題。
Active Record：解決降低應(yīng)用中面向?qū)ο髷?shù)據(jù)模型與數(shù)據(jù)庫(kù)中表結(jié)構(gòu)之間的耦合的問(wèn)題。
聯(lián)系客服
