1、架構設計的常常會“高來高去”。所謂高來高去，實際上就是我們的架構設計僅停留在模型階段，但也絕不是產生第一支樣例程式。
2、架構設計時常常會在某些方面過度設計（Over engineering）。為了一些根本不會發生的變化而進行一系列復雜的設計，這樣的設計就叫過度設計，往往會帶來資源的浪費并且會增加開發的工作量或難度。雖然我們必須考慮到系統的擴展性，可維護性等，但切忌過度設計。有時候或許你并不能判斷出哪些設計是過度設計，此時你可以請教你的PM，讓他站在整個項目的高度來幫你決策一下。
3、架構（Architecture）不是框架(Framework)，也不是簡單的將幾種框架或技術的組合，框架本身也是有架構的�？蚣芤话闶轻槍τ谀骋环矫婊蝾I域的重用性和可擴展性非常好的半成品，我們可以用一句較為經典的話來總結：框架是軟件，架構不是軟件，框架是一種特殊的軟件。我們在工作中通過將許多方面的可重用的工具類，公共類，基礎類等抽象出來，即可形成一些可重用的框架。
4、架構設計絕不是新技術展示平臺，合適的技術才是對于項目有利的技術，必須考慮到開發人員的能力和維護人員的能力。作為一名架構設計師應該更多的考慮如何平衡業務需求，織織運作（主要指團隊中的協作）和技術三者的關系，而不僅僅是去關注那些技術細節。
5、架構設計的成功與否決定著系統品質的好壞，因為架構設計不好而導致交付的系統Bug過多，無法滿足客戶非功能性需求等問題，從而導致項目取消的案例時有發生。架構設計不是架構設計師一個人的事情，也不是幾天就能完成的一項工作，必須是架構設計師付出大量辛勤勞動后的成果，其成敗往往與組織、主管、項目經理的支持有著密切的關系。
關于架構設計的一點通用技巧
1、分層（Layer）規則。這里的層是指邏輯上的層次（Layer），并非指物理上的層次（Tier）。目前的絕大多數的企業級應用系統中都分為三層，即表現層，領域層和數據層。在對各層次進行劃分時，主要可以從以下幾個方面來考慮：A、每一層是一個相對獨立的部分，可以作為一個整體，無需對其它層了解；B、將層次間的依賴性降到最低，即降低耦合；C、可以從某種程度上替換掉某一層，而對其它層不會產生過多的影響；D，層次并不能封閉所有的東西，假如用戶界面上增加了一個欄位，那么領域層就要增加一個數據域，數據層就要增加一個相應的字段。同時，過多的分層可能會對性能造成一定的影響。
2、包（package）之間不要產生循環依賴。通常包的劃分會先按不同的邏輯層來劃分，在層的包下面再按功能來劃分。避免包間的循環依賴是一個比較通用的規則，這樣的規則一定有其存在的價值和道理，之所以這樣主要是出于以下原因：A、循環依賴會使分層失去意義；B、循環依賴會帶來許多潛在的風險，如可能會產生嵌套事務（nested transaction，JavaEE標準中并不支持這種事務）的現象，我就曾遇到過這樣的問題，在一個項目中，事務放在業務邏輯層統一控制，但由于開發人員忽視了架構中這樣的原則，在持久層調用了展現層的公用類，形成了回圈的現象，導致了嵌套事務的發生。
3、設計模式的應用。在很多人的觀念里，提供設計模式就等同于GOF的設計模式，其實設計模式是個廣泛的概念，比如需求模式、領域模式、反模式等都屬于設計模式。模式其實是一門工具，是人們對于過去解決某一類問題的經驗總結，所以我們可以在設計活動中應用各種設計模式，但是在應用這些模式之前一定要先分析清楚問題，否則就可能出現“牛頭不對馬嘴”的現象。
成功的項目總有相似之處，失敗的項目卻各有各的失敗之處。好的軟件架構設計必定是成功項目的相似之處，我們有什么理由不把軟件架構設計做好了？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
