對于外包業務類型的項目，軟體架構設計的目的與産品類型的項目有所不同，在這裡主要讨論外包類型項目的軟體架構設計目的。
1、為大規模開發提供基礎和規範，并提供可重用的資産，軟體系統的大規模開發，必須要有一定的基礎和遵循一定的規範，這既是軟體工程本身的要求，也是客戶的要求。架構設計的過程中可以将一些公共部分抽象提取出來，形成公共類和工具類，以達到重用的目的。
2、一定程度上縮短項目的周期，利用軟體架構提供的架構或重用元件，縮短項目開發的周期。
3、降低開發和維護的成本，大量的重用和抽象，可以提取出一些開發人員不用關心的公共部分，這樣便可以使開發人員僅僅關注于業務邏輯的實作，進而減少了很多工作量，提高了開發效率。
4、提高産品的品質，好的軟體架構設計是産品品質的保證，特别是對于客戶常常提出的非功能性需求的滿足。
軟體架構設計的原則軟體架構設計必須遵循以下原則：
1、滿足功能性需求和非功能需求。這是一個軟體系統最基本的要求，也是架構設計時應該遵循的最基本的原則。
2、實用性原則，就像每一個軟體系統傳遞給使用者使用時必須實用，能解決使用者的問題一樣，架構設計也必須實用，否則就會“高來高去”或“過度設計”。
3、滿足複用的要求，最大程度的提高開發人員的工作效率。
軟體架構設計的幾種視圖我們常常在讨論架構設計該做些什麼的時候，或是在架構設計評審的會議上，會提出各種各樣的問題，例如開發人員該如何記錄Log，事務如何控制？怎樣才能提高我們的開發人員的工作效率，即在機關時間内更有品質的完成更多的功能？怎樣滿足客戶的非功能性需求？怎樣讓生産環境的平台管理人員更好的維護系統？
上面這些問題，實際上是軟體系統的不同的幹系人站在不同的角度上提出的問題，要回答上面這些問題，我們就得從不同的視角來看待軟體架構設計這項工作。
1、邏輯架構視角，從系統使用者的角度考慮問題，設計出來的軟體架構能夠滿足業務邏輯的需求，能夠處理現在越來越複雜的業務邏輯需求。
2、開發架構視角，從系統開發人員的角度來考慮問題，設計的架構要易于了解，易于開發，易于單元測試，最好做到讓開發人員可以用最少的代碼行數完成功能的開發。
3、運作架構視角，從系統運作時的品質需求考慮問題，特别關注于系統的非功能需求，客戶常常都會要求我們系統的功能畫面的最長響應時間不超過4秒，能滿足2000個使用者同時線上使用，基于角色的系統資源的安全控制等。
4、實體架構視角，關注系統安裝和部署在什麼樣的環境上，例如現在最流行的企業應用服務解決方案IBM Http Server ＋WebSphere Application Server ＋ DB2，WebLogic + Oracle等。
5、資料架構視角，如今我們開發的各類系統，如MIS，ERP，SAP，基本上都是對各類資料的操作，把一堆不太好懂的資料展現成使用者容易看懂的資料，自動處理各類資料的運算等，是以資料的持久化是十分重要的一件事情。
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時，通常可能會以會議的形式進行Review，是以我們可以參照評審會議時好的做法來召開會議，在這裡就不再冗述。
軟體架構設計的常見誤區及解決辦法1、架構設計的常常會“高來高去”。所謂高來高去，實際上就是我們的架構設計僅停留在模型階段，但也絕不是産生第一支樣例程式。
2、架構設計時常常會在某些方面過度設計（Over engineering）。為了一些根本不會發生的變化而進行一系列複雜的設計，這樣的設計就叫過度設計，往往會帶來資源的浪費并且會增加開發的工作量或難度。雖然我們必須考慮到系統的擴充性，可維護性等，但切忌過度設計。有時候或許你并不能判斷出哪些設計是過度設計，此時你可以請教你的PM，讓他站在整個項目的高度來幫你決策一下。
3、架構（Architecture）不是架構(Framework)，也不是簡單的将幾種架構或技術的組合，架構本身也是有架構的。架構一般是針對于某一方面或領域的重用性和可擴充性非常好的半成品，我們可以用一句較為經典的話來總結：架構是軟體，架構不是軟體，架構是一種特殊的軟體。我們在工作中通過将許多方面的可重用的工具類，公共類，基礎類等抽象出來，即可形成一些可重用的架構。
4、架構設計絕不是新技術展示平台，合适的技術才是對于項目有利的技術，必須考慮到開發人員的能力和維護人員的能力。作為一名架構設計師應該更多的考慮如何平衡業務需求，織織運作（主要指團隊中的協作）和技術三者的關系，而不僅僅是去關注那些技術細節。
5、架構設計的成功與否決定着系統品質的好壞，因為架構設計不好而導緻傳遞的系統Bug過多，無法滿足客戶非功能性需求等問題，進而導緻項目取消的案例時有發生。架構設計不是架構設計師一個人的事情，也不是幾天就能完成的一項工作，必須是架構設計師付出大量辛勤勞動後的成果，其成敗往往與組織、主管、項目經理的支援有着密切的關系。
關于架構設計的一點通用技巧1、分層（Layer）規則。這裡的層是指邏輯上的層次（Layer），并非指實體上的層次（Tier）。目前的絕大多數的企業級應用系統中都分為三層，即表現層，領域層和資料層。在對各層次進行劃分時，主要可以從以下幾個方面來考慮：A、每一層是一個相對獨立的部分，可以作為一個整體，無需對其它層了解；B、将層次間的依賴性降到最低，即降低耦合；C、可以從某種程度上替換掉某一層，而對其它層不會産生過多的影響；D，層次并不能封閉所有的東西，假如使用者界面上增加了一個欄位，那麼領域層就要增加一個資料域，資料層就要增加一個相應的字段。同時，過多的分層可能會對性能造成一定的影響。
2、包（package）之間不要産生循環依賴。通常包的劃分會先按不同的邏輯層來劃分，在層的包下面再按功能來劃分。避免包廂的循環依賴是一個比較通用的規則，這樣的規則一定有其存在的價值和道理，之是以這樣主要是出于以下原因：A、循環依賴會使分層失去意義；B、循環依賴會帶來許多潛在的風險，如可能會産生嵌套事務（nested transaction，JavaEE标準中并不支援這種事務）的現象，我就曾遇到過這樣的問題，在一個項目中，事務放在業務邏輯層統一控制，但由于開發人員忽視了架構中這樣的原則，在持久層調用了展現層的公用類，形成了回圈的現象，導緻了嵌套事務的發生。
3、設計模式的應用。在很多人的觀念裡，提供設計模式就等同于GOF的設計模式，其實設計模式是個廣泛的概念，比如需求模式、領域模式、反模式等都屬于設計模式。模式其實是一門工具，是人們對于過去解決某一類問題的經驗總結，是以我們可以在設計活動中應用各種設計模式，但是在應用這些模式之前一定要先分析清楚問題，否則就可能出現“牛頭不對馬嘴”的現象。
成功的項目總有相似之處，失敗的項目卻各有各的失敗之處。好的軟體架構設計必定是成功項目的相似之處，我們有什麼理由不把軟體架構設計做好了？
![Run-time error'339'[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)