這幾日，在閱讀GoF之一的John Vlissides著作《設(shè)計模式思考》，在James O. Coplien為本書所撰寫的序中，摘引了Richard Helm的一封郵件：
　　GoF的設(shè)計模式只解決了微觀架構(gòu)（micro-architecture）。你仍然必須把宏觀架構(gòu)（marco-architecture）設(shè)計好：分層、分布、功能隔離……。而且就像Cope說的，你仍然必須把納米架構(gòu)（nano-architecture）設(shè)計好：封裝、liskov……。
　　我很贊成這種根據(jù)設(shè)計粒度來劃分架構(gòu)的方式。從嚴(yán)格意義上講，軟件設(shè)計也可看做是架構(gòu)的一部分。從marco-architecture到micro-architecture，再到nano-architecture，是一種設(shè)計粒度的自上而下。但在架構(gòu)過程中，我們并非一定要從宏觀到微觀，再到更為具體的細(xì)節(jié)，這些架構(gòu)其實是平等的。這幾種粒度的架構(gòu)，似乎存在某些玄奧的原則與設(shè)計精神，貫穿其中。我以為，如果能把握它們之間的脈絡(luò)，甚至通過某種方式將它們串聯(lián)起來，形成一種有機結(jié)合或者說渾然一體的架構(gòu)，對于我們的架構(gòu)與設(shè)計而言，無疑會帶來極大的幫助。
　　最近一年來，我一直在思考隱藏在設(shè)計背后的基本思想與原則。因為在紛繁復(fù)雜的模式中，我們很容易迷失自己，要么患上模式病，要么在選擇模式方面變得無可適從，或者就干脆鄙視模式，按照自己的一套方法野蠻施工。不幸的是，這種野蠻施工在有時候確乎能取得不錯的效果。然而，這無疑落入了一種類似“按巧合編程”的反模式陷阱中，我將其稱之為“按巧合設(shè)計”，即在項目或產(chǎn)品設(shè)計過程中，因為偶然原因，設(shè)計取得成功，從而給設(shè)計者帶來錯覺，以為尋覓到了某種“放之四海皆準(zhǔn)”的終南捷徑。
　　我對設(shè)計的思考總結(jié)而言，包括七個方面，即“重用、擴展、變化、分離、簡約、一致、間接”。我在多次會議上也闡述和分享了我的這些想法（當(dāng)然，這些想法絕非我的獨創(chuàng)，有很多其實本身就是業(yè)界公認(rèn)的原則，我不過是期望能夠融為一體地來闡述架構(gòu)與設(shè)計這一命題。）然而，囿于自身經(jīng)驗與能力，我還未能將其總結(jié)得更好。我對設(shè)計模式（即所謂微觀架構(gòu)）的理解是有幾分自信的，對于OO的基本原則（即所謂納米架構(gòu)），也可以說是深諳于心，但對宏觀架構(gòu)的把握，還欠缺幾分火候。我始終感覺我的總結(jié)有一些散，我追求的設(shè)計原則，應(yīng)該像散文的精神那般，能夠做到“形散而神不散”，而現(xiàn)在對設(shè)計的理解正好缺乏某種能夠符合類似天體運行規(guī)律的鏈條所在。Richard Helm對架構(gòu)的敘述，為我打開了一扇窗戶。
　　此外，通過我這幾個月負(fù)責(zé)的產(chǎn)品研發(fā)，我對UML的理解也更近了一層。我越來越覺得UML對架構(gòu)和設(shè)計的幫助。正如Craig Larman的那本名著《Applying UML and Patterns》，UML與模式可以結(jié)合得更緊密一些。UML的重要性不言而喻，如果有人對其產(chǎn)生輕視，乃至于鄙視，歸根結(jié)底，一定是對UML進(jìn)行了誤用或者濫用。UML是工具，但它不同于普通的工具，它能夠啟發(fā)我們的設(shè)計。例如用例圖可以幫助我們識辨角色與場景，還可以幫助我們找到能夠重用的元素。組件圖無疑屬于宏觀架構(gòu)的范疇，它幫助我們體會封裝與松散耦合，還能夠幫助我們定義服務(wù)。我不認(rèn)為從一開始，就只能利用組件圖來劃分模塊，畢竟在很多時候，我們很難完全對模塊進(jìn)行分解。但如果能夠合理地利用組件圖，對模塊的劃分無疑會變得輕松許多。在微觀架構(gòu)的層面，我特別喜歡時序圖（sequence diagram），在我心中，它的重要性甚至勝過測試驅(qū)動開發(fā)。結(jié)合用例圖，它能夠幫助我們找到對象協(xié)作的順序與方式，幫助我們找到抽象以及接口，當(dāng)然還包括對象的職責(zé)。我們還可以適當(dāng)?shù)亟Y(jié)合ICONIX方法，并結(jié)合原型，來幫助我們對用例場景的理解，并最后找到必須、應(yīng)該且恰如其分地需要參與到這一場景中的業(yè)務(wù)對象。
　　從架構(gòu)的角度來看，我們需要將自上而下與自下而上兩種方式進(jìn)行結(jié)合。此外，我們必須遵循所有層級架構(gòu)都應(yīng)遵循的原則，例如高內(nèi)聚、松耦合以及關(guān)注點分離。我在思考，這些基本原則，似乎正是我要尋找的穿起納米架構(gòu)、微觀架構(gòu)和宏觀架構(gòu)的鏈條呢？如果是，我們該怎樣運用它們。畢竟，對于大多數(shù)設(shè)計者而言，這些原則都太空泛，太抽象，以至于落入玄奧的“道”中無可自拔。架構(gòu)與設(shè)計自然有其玄妙之處，有其不可言傳之處，但如果一味地故弄玄虛，并不利于設(shè)計者的提高。因此，對我而言，我希望能夠提供大量的案例，來佐證這些原則；更重要的不是佐證，而是指引，以好的例子，甚至可以稱為典范的例子，展現(xiàn)這些精妙的原則，使得我們的開發(fā)人員都能夠看懂，都能夠理解設(shè)計的妙處。這是我努力期望做到的。
　　若要做到這一點，我必須還要提高自己的架構(gòu)與設(shè)計水平。但我以為，我?guī)缀跻獙ひ挼降翘萌胧业娜肟谒诹恕Ｎ移诖约耗茉缫惶煺业剿?/p>

it知識庫：對架構(gòu)的思考，轉(zhuǎn)載需保留來源！

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