❶ 如何進行軟體架構設計
軟體架構設計的幾個步驟 1、分析需求和理解業務模型（或領域建模），並選定關鍵Use case。 軟體的需求，可以分為從用戶視角和開發人員視角來看，從用戶的角度看，又可以分為功能性和非功能性需求，我們必須從不同的視角和級別去全面的認識需求並分析需求，理解業務模型。實踐表明，常常被我們忽視的非功能性需求常常會導致整個項目失敗。 理解業務需求最好的方式莫過於進行領域建模，領域建模與需求分析往往是交替穿叉進行的，領域建模主要有以下三個方面的作用： ◆探索復雜問題，弄清領域知識。Martin Fowler曾經說過，他採用面向對象方法最大的好處就是它有助於解決更為復雜的問題。領域建模本身作為輔助思維的工具，幫助我們將注意力始終保持在最為重要的業務概念及其關繫上，使我們能夠不斷深入地，系統的對需求進行分析和認識。領域建模往往是一個從模糊到清晰，從零散到系統的過程。 ◆決定功能范圍，影響可擴展性。任何模型都是對現實世界某種程序的抽象，這種抽象就會忽略某一些東西，例如忽略對象的屬性和對象間的關系，而這些忽略往往都是帶有一定的目的性的，這種忽略就決定了功能的范圍。模型揭示了各種功能背後的結構，如果說定義功能相當於「拍照片」的話，那麼領域建模就相當於「做透視」，更加關注問題領域的內在結構，相當於對問題領域進行了一定的抽象，良好的領域模型不僅能很好的支持現有的功能，而且還可以在一定程度上支持未來可能出現的新需求，體現良好的可擴展性。 ◆提供交流基礎，促進有效溝通。領域建模通常會使用UML圖作為呈現的方式，這樣為我們的溝通提供了方便。當然，有時候文字在描述某些特定領域的問題時可能更適合，可以靈活運用。 在我們公司的實際軟體開發流程中，往往領域建模缺少這一環節，這可能是在以後的工作中需要進一步提高之處。 雖然我們總是期望架構設計師能全面掌握需求，但由於時間和精力的限制，擺在我們面前的現實就是架構設計師沒有時間對所有需求進行深入分析，所以我們的策略就是「把好鋼用在刀刃上」，即把大部分時間和精力花在對決定架構最重要的關鍵需求上。在選擇關鍵需求時要注意：高優先順序的需求往往是從用戶的角度來看的，可能並不是真正的關鍵需求。在《RUP實踐者指南》一書中向我們講述了如何確定關鍵功能需求？A.作為應用程序的核心或實現了系統的主要介面的功能，B.必須被實現的功能，即如果這些功能不被實現，則開發出來的軟體就失去了價值，C.覆蓋了系統架構的一些方面，但沒有被其他重要的Use case覆蓋到的功能。 2、分別從各個視角來考慮軟體架構的方方面面。 軟體的架構設計必須考慮到各方面，根據前期工作確立的領域模型，關鍵需求，系統約束等進行設計，必須從系統用戶，開發人員，系統管理員，部署管理員，數據管理員等人員的角度去分析並解決問題。比如說，如果我們的運行架構採用Cluster方式時，就必須小心Cache和Session等的使用；如果我們的業務邏輯要求我們要操作多個資料庫時，就要考慮採用支持二階段事務提交的方式。 只有將這些方方面面的問題都考慮到了，這樣的架構設計才是完整的。至於每一個視圖中，我們應該設計到什麼細節這一問題，實際上與整個項目的過程定義有關。例如，如果我們有專門安排資料庫概要設計的活動，那我們在架構設計的過程中就可以只需要關注更高層次的資料庫特性及資料庫之間的關系，而每一張表的數據字典可以在後續的相關活動中進行設計，但如果沒有這樣的活動，那我們就要細化到每一張表的每一個欄位，以及表之間的關系。 3、解決技術面的重點問題和難題 在軟體架構設計的過程中，我們往往會需要攻克一些技術面的重點問題和難題，這完全是一項極其需要扎實的理論知識和豐富的實踐經驗支撐的工作。例如，我們如何提高整個系統的性能？如何能很好的導出極其復雜的「中國式報表」（一般比西方國家產出的報表要復雜很多，而且很多開源的BI類的框架並不能完全解決問題）？ 當遇到確實是很困難的問題，可以去網路一下或Google一下，也可以去請教公司的資深技術人員或專家，或者召開小范圍的技術專題討論會議，採用腦力激盪的方法試著找找答案，這樣才能提高工作的效率。 4、召開架構設計評審會議進行同行評審。 架構設計評審是極其重要的一環，我曾將其形容為「七種武器」中的離別鉤，就是因為在會議上，同行們可能會提很多問題或意見，而且很多意見很尖銳，所以一定要虛心接受，並做好記錄，正所謂「良葯苦口利於病，忠言逆耳利於行」。 在評審會議之前，我們要完成很多准備工作，最好是能准備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進行評審會議時，就不會漫無目的，在會議前就將這些資料發給與會人員，請他們抽空先了解一下，在會議進行時，要學會控制會議的進度，提高會議的效率。 5、針對關鍵Use case在設計的架構上實現功能來驗證架構。 對於架構設計的驗證也是一項十分重要的工作，其驗證技術有很多種，在我們公司通常會採用Sample的形式，即XP中所說的迭代0，RUP中所說的切片。這樣做的好處是既可以從實際的產品角度出發來有效的驗證架構是否滿足要求，又可以比拋棄型原型驗證技術節省成本。 這個Sample絕不是我們在解決架構設計中的問題時拿來做實驗的一些代碼的拼湊，而是完整的實現某一關鍵Use case的符合架構設計和一系列規范的可交付的代碼及相關文檔。同時，這個Sample可以作為你在給大家講解或培訓架構時的教材，也可以作為開發人員使用此架構進行開發的藍本，甚至是只需要復制粘貼，加上簡單的修改即可。 6、交付給客戶Review。 這一環節，在很多公司可能並不存在，因為他們的軟體架構並不一定需要客戶Review，但像我們這種做服務的公司，最重要的就是客尊，落實到軟體架構設計這一活動，就是讓客戶理解並接受你的架構設計方案，同時，客戶也會起到幫你驗證架構的作用。通常，我們的架構得到客戶的認可後，便可進入大規模的開發。 在交付給客戶Review時，通常