軟件架構(gòu)設(shè)計(jì)的目的

    對(duì)于外包業(yè)務(wù)類型的項(xiàng)目，軟件架構(gòu)設(shè)計(jì)的目的與產(chǎn)品類型的項(xiàng)目有所不同，在這里主要討論外包類型項(xiàng)目的軟件架構(gòu)設(shè)計(jì)目的。

    1、為大規(guī)模開發(fā)提供基礎(chǔ)和規(guī)范，并提供可重用的資產(chǎn)，軟件系統(tǒng)的大規(guī)模開發(fā)，必須要有一定的基礎(chǔ)和遵循一定的規(guī)范，這既是軟件工程本身的要求，也是客戶的要求。架構(gòu)設(shè)計(jì)的過(guò)程中可以將一些公共部分抽象提取出來(lái)，形成公共類和工具類，以達(dá)到重用的目的。

    2、一定程度上縮短項(xiàng)目的周期，利用軟件架構(gòu)提供的框架或重用組件，縮短項(xiàng)目開發(fā)的周期。

    3、降低開發(fā)和維護(hù)的成本，大量的重用和抽象，可以提取出一些開發(fā)人員不用關(guān)心的公共部分，這樣便可以使開發(fā)人員僅僅關(guān)注于業(yè)務(wù)邏輯的實(shí)現(xiàn)，從而減少了很多工作量，提高了開發(fā)效率。

    4、提高產(chǎn)品的質(zhì)量，好的軟件架構(gòu)設(shè)計(jì)是產(chǎn)品質(zhì)量的保證，特別是對(duì)于客戶常常提出的非功能性需求的滿足。

    軟件架構(gòu)設(shè)計(jì)的原則

    軟件架構(gòu)設(shè)計(jì)必須遵循以下原則：

    1、滿足功能性需求和非功能需求。這是一個(gè)軟件系統(tǒng)最基本的要求，也是架構(gòu)設(shè)計(jì)時(shí)應(yīng)該遵循的最基本的原則。

    2、實(shí)用性原則，就像每一個(gè)軟件系統(tǒng)交付給用戶使用時(shí)必須實(shí)用，能解決用戶的問題一樣，架構(gòu)設(shè)計(jì)也必須實(shí)用，否則就會(huì)“高來(lái)高去”或“過(guò)度設(shè)計(jì)”。

    3、滿足復(fù)用的要求，最大程度的提高開發(fā)人員的工作效率。

    軟件架構(gòu)設(shè)計(jì)的幾種視圖

    我們常常在討論架構(gòu)設(shè)計(jì)該做些什么的時(shí)候，或是在架構(gòu)設(shè)計(jì)評(píng)審的會(huì)議上，會(huì)提出各種各樣的問題，例如開發(fā)人員該如何記錄Log，事務(wù)如何控制？怎樣才能提高我們的開發(fā)人員的工作效率，即在單位時(shí)間內(nèi)更有品質(zhì)的完成更多的功能？怎樣滿足客戶的非功能性需求？怎樣讓生產(chǎn)環(huán)境的平臺(tái)管理人員更好的維護(hù)系統(tǒng)？

    上面這些問題，實(shí)際上是軟件系統(tǒng)的不同的干系人站在不同的角度上提出的問題，要回答上面這些問題，我們就得從不同的視角來(lái)看待軟件架構(gòu)設(shè)計(jì)這項(xiàng)工作。

    1、邏輯架構(gòu)視角，從系統(tǒng)用戶的角度考慮問題，設(shè)計(jì)出來(lái)的軟件架構(gòu)能夠滿足業(yè)務(wù)邏輯的需求，能夠處理現(xiàn)在越來(lái)越復(fù)雜的業(yè)務(wù)邏輯需求。

    2、開發(fā)架構(gòu)視角，從系統(tǒng)開發(fā)人員的角度來(lái)考慮問題，設(shè)計(jì)的架構(gòu)要易于理解，易于開發(fā)，易于單元測(cè)試，最好做到讓開發(fā)人員可以用最少的代碼行數(shù)完成功能的開發(fā)。

    3、運(yùn)行架構(gòu)視角，從系統(tǒng)運(yùn)行時(shí)的質(zhì)量需求考慮問題，特別關(guān)注于系統(tǒng)的非功能需求，客戶常常都會(huì)要求我們系統(tǒng)的功能畫面的最長(zhǎng)響應(yīng)時(shí)間不超過(guò)4秒，能滿足2000個(gè)用戶同時(shí)在線使用，基于角色的系統(tǒng)資源的安全控制等。

    4、物理架構(gòu)視角，關(guān)注系統(tǒng)安裝和部署在什么樣的環(huán)境上，例如現(xiàn)在最流行的企業(yè)應(yīng)用服務(wù)解決方案IBM Http Server ＋ WebSphere Application Server ＋ DB2，WebLogic + Oracle等。

    5、數(shù)據(jù)架構(gòu)視角，如今我們開發(fā)的各類系統(tǒng)，如MIS，ERP，SAP，基本上都是對(duì)各類數(shù)據(jù)的操作，把一堆不太好懂的數(shù)據(jù)展現(xiàn)成用戶容易看懂的數(shù)據(jù)，自動(dòng)處理各類數(shù)據(jù)的運(yùn)算等，所以數(shù)據(jù)的持久化是十分重要的一件事情。

1

1、分析需求和理解業(yè)務(wù)模型（或領(lǐng)域建模），并選定關(guān)鍵Use case。

    軟件的需求，可以分為從用戶視角和開發(fā)人員視角來(lái)看，從用戶的角度看，又可以分為功能性和非功能性需求，我們必須從不同的視角和級(jí)別去全面的認(rèn)識(shí)需求并分析需求，理解業(yè)務(wù)模型。實(shí)踐表明，常常被我們忽視的非功能性需求常常會(huì)導(dǎo)致整個(gè)項(xiàng)目失敗。

    理解業(yè)務(wù)需求最好的方式莫過(guò)于進(jìn)行領(lǐng)域建模，領(lǐng)域建模與需求分析往往是交替穿叉進(jìn)行的，領(lǐng)域建模主要有以下三個(gè)方面的作用：

    ◆探索復(fù)雜問題，弄清領(lǐng)域知識(shí)。Martin Fowler曾經(jīng)說(shuō)過(guò)，他采用面向?qū)ο蠓椒ㄗ畲蟮暮锰幘褪撬兄诮鉀Q更為復(fù)雜的問題。領(lǐng)域建模本身作為輔助思維的工具，幫助我們將注意力始終保持在最為重要的業(yè)務(wù)概念及其關(guān)系上，使我們能夠不斷深入地，系統(tǒng)的對(duì)需求進(jìn)行分析和認(rèn)識(shí)。領(lǐng)域建模往往是一個(gè)從模糊到清晰，從零散到系統(tǒng)的過(guò)程。

    ◆決定功能范圍，影響可擴(kuò)展性。任何模型都是對(duì)現(xiàn)實(shí)世界某種程序的抽象，這種抽象就會(huì)忽略某一些東西，例如忽略對(duì)象的屬性和對(duì)象間的關(guān)系，而這些忽略往往都是帶有一定的目的性的，這種忽略就決定了功能的范圍。模型揭示了各種功能背后的結(jié)構(gòu)，如果說(shuō)定義功能相當(dāng)于“拍照片”的話，那么領(lǐng)域建模就相當(dāng)于“做透視”，更加關(guān)注問題領(lǐng)域的內(nèi)在結(jié)構(gòu)，相當(dāng)于對(duì)問題領(lǐng)域進(jìn)行了一定的抽象，良好的領(lǐng)域模型不僅能很好的支持現(xiàn)有的功能，而且還可以在一定程度上支持未來(lái)可能出現(xiàn)的新需求，體現(xiàn)良好的可擴(kuò)展性。

    ◆提供交流基礎(chǔ)，促進(jìn)有效溝通。領(lǐng)域建模通常會(huì)使用UML圖作為呈現(xiàn)的方式，這樣為我們的溝通提供了方便。當(dāng)然，有時(shí)候文字在描述某些特定領(lǐng)域的問題時(shí)可能更適合，可以靈活運(yùn)用。

    在我們公司的實(shí)際軟件開發(fā)流程中，往往領(lǐng)域建模缺少這一環(huán)節(jié)，這可能是在以后的工作中需要進(jìn)一步提高之處。

    雖然我們總是期望架構(gòu)設(shè)計(jì)師能全面掌握需求，但由于時(shí)間和精力的限制，擺在我們面前的現(xiàn)實(shí)就是架構(gòu)設(shè)計(jì)師沒有時(shí)間對(duì)所有需求進(jìn)行深入分析，所以我們的策略就是“把好鋼用在刀刃上”，即把大部分時(shí)間和精力花在對(duì)決定架構(gòu)最重要的關(guān)鍵需求上。在選擇關(guān)鍵需求時(shí)要注意：高優(yōu)先級(jí)的需求往往是從用戶的角度來(lái)看的，可能并不是真正的關(guān)鍵需求。在《RUP實(shí)踐者指南》一書中向我們講述了如何確定關(guān)鍵功能需求？A.作為應(yīng)用程序的核心或?qū)崿F(xiàn)了系統(tǒng)的主要接口的功能，B.必須被實(shí)現(xiàn)的功能，即如果這些功能不被實(shí)現(xiàn)，則開發(fā)出來(lái)的軟件就失去了價(jià)值，C.覆蓋了系統(tǒng)架構(gòu)的一些方面，但沒有被其他重要的Use case覆蓋到的功能。

    2、分別從各個(gè)視角來(lái)考慮軟件架構(gòu)的方方面面。

    軟件的架構(gòu)設(shè)計(jì)必須考慮到各方面，根據(jù)前期工作確立的領(lǐng)域模型，關(guān)鍵需求，系統(tǒng)約束等進(jìn)行設(shè)計(jì)，必須從系統(tǒng)用戶，開發(fā)人員，系統(tǒng)管理員，部署管理員，數(shù)據(jù)管理員等人員的角度去分析并解決問題。比如說(shuō)，如果我們的運(yùn)行架構(gòu)采用Cluster方式時(shí)，就必須小心Cache和Session等的使用；如果我們的業(yè)務(wù)邏輯要求我們要操作多個(gè)數(shù)據(jù)庫(kù)時(shí)，就要考慮采用支持二階段事務(wù)提交的方式。

    只有將這些方方面面的問題都考慮到了，這樣的架構(gòu)設(shè)計(jì)才是完整的。至于每一個(gè)視圖中，我們應(yīng)該設(shè)計(jì)到什么細(xì)節(jié)這一問題，實(shí)際上與整個(gè)項(xiàng)目的過(guò)程定義有關(guān)。例如，如果我們有專門安排數(shù)據(jù)庫(kù)概要設(shè)計(jì)的活動(dòng)，那我們?cè)诩軜?gòu)設(shè)計(jì)的過(guò)程中就可以只需要關(guān)注更高層次的數(shù)據(jù)庫(kù)特性及數(shù)據(jù)庫(kù)之間的關(guān)系，而每一張表的數(shù)據(jù)字典可以在后續(xù)的相關(guān)活動(dòng)中進(jìn)行設(shè)計(jì)，但如果沒有這樣的活動(dòng)，那我們就要細(xì)化到每一張表的每一個(gè)欄位，以及表之間的關(guān)系。

    3、解決技術(shù)面的重點(diǎn)問題和難題

    在軟件架構(gòu)設(shè)計(jì)的過(guò)程中，我們往往會(huì)需要攻克一些技術(shù)面的重點(diǎn)問題和難題，這完全是一項(xiàng)極其需要扎實(shí)的理論知識(shí)和豐富的實(shí)踐經(jīng)驗(yàn)支撐的工作。例如，我們?nèi)绾翁岣哒麄€(gè)系統(tǒng)的性能？如何能很好的導(dǎo)出極其復(fù)雜的“中國(guó)式報(bào)表”（一般比西方國(guó)家產(chǎn)出的報(bào)表要復(fù)雜很多，而且很多開源的BI類的框架并不能完全解決問題）？

    當(dāng)遇到確實(shí)是很困難的問題，可以去百度一下或Google一下，也可以去請(qǐng)教公司的資深技術(shù)人員或?qū)＜?，或者召開小范圍的技術(shù)專題討論會(huì)議，采用腦力激蕩的方法試著找找答案，這樣才能提高工作的效率。

    4、召開架構(gòu)設(shè)計(jì)評(píng)審會(huì)議進(jìn)行同行評(píng)審。

    架構(gòu)設(shè)計(jì)評(píng)審是極其重要的一環(huán)，我曾將其形容為“七種武器”中的離別鉤，就是因?yàn)樵跁?huì)議上，同行們可能會(huì)提很多問題或意見，而且很多意見很尖銳，所以一定要虛心接受，并做好記錄，正所謂“良藥苦口利于病，忠言逆耳利于行”。

    在評(píng)審會(huì)議之前，我們要完成很多準(zhǔn)備工作，最好是能準(zhǔn)備一份簡(jiǎn)明扼要的電子簡(jiǎn)報(bào)，把最重要的問題列出來(lái)，這樣在進(jìn)行評(píng)審會(huì)議時(shí)，就不會(huì)漫無(wú)目的，在會(huì)議前就將這些資料發(fā)給與會(huì)人員，請(qǐng)他們抽空先了解一下，在會(huì)議進(jìn)行時(shí)，要學(xué)會(huì)控制會(huì)議的進(jìn)度，提高會(huì)議的效率。

    5、針對(duì)關(guān)鍵Use case在設(shè)計(jì)的架構(gòu)上實(shí)現(xiàn)功能來(lái)驗(yàn)證架構(gòu)。

    對(duì)于架構(gòu)設(shè)計(jì)的驗(yàn)證也是一項(xiàng)十分重要的工作，其驗(yàn)證技術(shù)有很多種，在我們公司通常會(huì)采用Sample的形式，即XP中所說(shuō)的迭代0，RUP中所說(shuō)的切片。這樣做的好處是既可以從實(shí)際的產(chǎn)品角度出發(fā)來(lái)有效的驗(yàn)證架構(gòu)是否滿足要求，又可以比拋棄型原型驗(yàn)證技術(shù)節(jié)省成本。

    這個(gè)Sample絕不是我們?cè)诮鉀Q架構(gòu)設(shè)計(jì)中的問題時(shí)拿來(lái)做實(shí)驗(yàn)的一些代碼的拼湊，而是完整的實(shí)現(xiàn)某一關(guān)鍵Use case的符合架構(gòu)設(shè)計(jì)和一系列規(guī)范的可交付的代碼及相關(guān)文檔。同時(shí)，這個(gè)Sample可以作為你在給大家講解或培訓(xùn)架構(gòu)時(shí)的教材，也可以作為開發(fā)人員使用此架構(gòu)進(jìn)行開發(fā)的藍(lán)本，甚至是只需要復(fù)制粘貼，加上簡(jiǎn)單的修改即可。

    6、交付給客戶Review。

    這一環(huán)節(jié)，在很多公司可能并不存在，因?yàn)樗麄兊能浖軜?gòu)并不一定需要客戶Review，但像我們這種做服務(wù)的公司，最重要的就是客尊，落實(shí)到軟件架構(gòu)設(shè)計(jì)這一活動(dòng)，就是讓客戶理解并接受你的架構(gòu)設(shè)計(jì)方案，同時(shí)，客戶也會(huì)起到幫你驗(yàn)證架構(gòu)的作用。通常，我們的架構(gòu)得到客戶的認(rèn)可后，便可進(jìn)入大規(guī)模的開發(fā)。

    在交付給客戶Review時(shí)，通?？赡軙?huì)以會(huì)議的形式進(jìn)行Review，所以我們可以參照評(píng)審會(huì)議時(shí)好的做法來(lái)召開會(huì)議，在這里就不再冗述。

1

軟件架構(gòu)設(shè)計(jì)的常見誤區(qū)及解決辦法 

    1、架構(gòu)設(shè)計(jì)的常常會(huì)“高來(lái)高去”。所謂高來(lái)高去，實(shí)際上就是我們的架構(gòu)設(shè)計(jì)僅停留在模型階段，但也絕不是產(chǎn)生第一支樣例程式。

    2、架構(gòu)設(shè)計(jì)時(shí)常常會(huì)在某些方面過(guò)度設(shè)計(jì)（Over engineering）。為了一些根本不會(huì)發(fā)生的變化而進(jìn)行一系列復(fù)雜的設(shè)計(jì)，這樣的設(shè)計(jì)就叫過(guò)度設(shè)計(jì)，往往會(huì)帶來(lái)資源的浪費(fèi)并且會(huì)增加開發(fā)的工作量或難度。雖然我們必須考慮到系統(tǒng)的擴(kuò)展性，可維護(hù)性等，但切忌過(guò)度設(shè)計(jì)。有時(shí)候或許你并不能判斷出哪些設(shè)計(jì)是過(guò)度設(shè)計(jì)，此時(shí)你可以請(qǐng)教你的PM，讓他站在整個(gè)項(xiàng)目的高度來(lái)幫你決策一下。

    3、架構(gòu)（Architecture）不是框架(Framework)，也不是簡(jiǎn)單的將幾種框架或技術(shù)的組合，框架本身也是有架構(gòu)的。框架一般是針對(duì)于某一方面或領(lǐng)域的重用性和可擴(kuò)展性非常好的半成品，我們可以用一句較為經(jīng)典的話來(lái)總結(jié)：框架是軟件，架構(gòu)不是軟件，框架是一種特殊的軟件。我們?cè)诠ぷ髦型ㄟ^(guò)將許多方面的可重用的工具類，公共類，基礎(chǔ)類等抽象出來(lái)，即可形成一些可重用的框架。

    4、架構(gòu)設(shè)計(jì)絕不是新技術(shù)展示平臺(tái)，合適的技術(shù)才是對(duì)于項(xiàng)目有利的技術(shù)，必須考慮到開發(fā)人員的能力和維護(hù)人員的能力。作為一名架構(gòu)設(shè)計(jì)師應(yīng)該更多的考慮如何平衡業(yè)務(wù)需求，織織運(yùn)作（主要指團(tuán)隊(duì)中的協(xié)作）和技術(shù)三者的關(guān)系，而不僅僅是去關(guān)注那些技術(shù)細(xì)節(jié)。

    5、架構(gòu)設(shè)計(jì)的成功與否決定著系統(tǒng)品質(zhì)的好壞，因?yàn)榧軜?gòu)設(shè)計(jì)不好而導(dǎo)致交付的系統(tǒng)Bug過(guò)多，無(wú)法滿足客戶非功能性需求等問題，從而導(dǎo)致項(xiàng)目取消的案例時(shí)有發(fā)生。架構(gòu)設(shè)計(jì)不是架構(gòu)設(shè)計(jì)師一個(gè)人的事情，也不是幾天就能完成的一項(xiàng)工作，必須是架構(gòu)設(shè)計(jì)師付出大量辛勤勞動(dòng)后的成果，其成敗往往與組織、主管、項(xiàng)目經(jīng)理的支持有著密切的關(guān)系。

    關(guān)于架構(gòu)設(shè)計(jì)的一點(diǎn)通用技巧

    1、分層（Layer）規(guī)則。這里的層是指邏輯上的層次（Layer），并非指物理上的層次（Tier）。目前的絕大多數(shù)的企業(yè)級(jí)應(yīng)用系統(tǒng)中都分為三層，即表現(xiàn)層，領(lǐng)域?qū)雍蛿?shù)據(jù)層。在對(duì)各層次進(jìn)行劃分時(shí)，主要可以從以下幾個(gè)方面來(lái)考慮：A、每一層是一個(gè)相對(duì)獨(dú)立的部分，可以作為一個(gè)整體，無(wú)需對(duì)其它層了解；B、將層次間的依賴性降到最低，即降低耦合；C、可以從某種程度上替換掉某一層，而對(duì)其它層不會(huì)產(chǎn)生過(guò)多的影響；D，層次并不能封閉所有的東西，假如用戶界面上增加了一個(gè)欄位，那么領(lǐng)域?qū)泳鸵黾右粋€(gè)數(shù)據(jù)域，數(shù)據(jù)層就要增加一個(gè)相應(yīng)的字段。同時(shí)，過(guò)多的分層可能會(huì)對(duì)性能造成一定的影響。

    2、包（package）之間不要產(chǎn)生循環(huán)依賴。通常包的劃分會(huì)先按不同的邏輯層來(lái)劃分，在層的包下面再按功能來(lái)劃分。避免包間的循環(huán)依賴是一個(gè)比較通用的規(guī)則，這樣的規(guī)則一定有其存在的價(jià)值和道理，之所以這樣主要是出于以下原因：A、循環(huán)依賴會(huì)使分層失去意義；B、循環(huán)依賴會(huì)帶來(lái)許多潛在的風(fēng)險(xiǎn)，如可能會(huì)產(chǎn)生嵌套事務(wù)（nested transaction，JavaEE標(biāo)準(zhǔn)中并不支持這種事務(wù)）的現(xiàn)象，我就曾遇到過(guò)這樣的問題，在一個(gè)項(xiàng)目中，事務(wù)放在業(yè)務(wù)邏輯層統(tǒng)一控制，但由于開發(fā)人員忽視了架構(gòu)中這樣的原則，在持久層調(diào)用了展現(xiàn)層的公用類，形成了回圈的現(xiàn)象，導(dǎo)致了嵌套事務(wù)的發(fā)生。

    3、設(shè)計(jì)模式的應(yīng)用。在很多人的觀念里，提供設(shè)計(jì)模式就等同于GOF的設(shè)計(jì)模式，其實(shí)設(shè)計(jì)模式是個(gè)廣泛的概念，比如需求模式、領(lǐng)域模式、反模式等都屬于設(shè)計(jì)模式。模式其實(shí)是一門工具，是人們對(duì)于過(guò)去解決某一類問題的經(jīng)驗(yàn)總結(jié)，所以我們可以在設(shè)計(jì)活動(dòng)中應(yīng)用各種設(shè)計(jì)模式，但是在應(yīng)用這些模式之前一定要先分析清楚問題，否則就可能出現(xiàn)“牛頭不對(duì)馬嘴”的現(xiàn)象。

    成功的項(xiàng)目總有相似之處，失敗的項(xiàng)目卻各有各的失敗之處。好的軟件架構(gòu)設(shè)計(jì)必定是成功項(xiàng)目的相似之處，我們有什么理由不把軟件架構(gòu)設(shè)計(jì)做好了？

1