在網上也看了很多東西，關於JAVA軟件架構方面的東西，現在還真是很難找到，不過，軟件開發的架構基本是相同的。所以，我在網上查找了很多其他語言關於軟件架構方面的文章。再這裏也來說說自己對軟件架構，特別是在JAVA項目架構方面的看法。說得不一定對，但這也是我幾年來的總結吧。
1. 儘量不要考慮項目外的重用
許多人認爲能提高軟件的重用度是最好的，然而每個項目實際情況都會有所不同，在設計項目中的某個模塊、方法時，過多的考慮項目外的重用，必然會增加項目的複雜度，增加對開發時間的開銷。也許有人會說，這會減少下一項目的開銷，試問，下一項目是什麼項目?有什麼需求?各方面有什麼影響因素?有誰會在當前知道這一切。 如果真要重用，應該是在項目結束後再將可重用的部分提取出來，經過修改、優化後做爲企業的可重用資產，而不是當前項目中的一廂情願。考慮項目外的重用性，這是很多剛從事軟件工作的程序員常犯的錯誤，往往是考慮得越多，反而做出來的軟件達不到設計的效果，完不成基本的功能或者代碼邏輯過多，程序功能不完善等等。
2.經常檢查項目架構
項目架構通常是在項目實現開始前就已確定的東西，是一個總體的設計。然而，在這時，對項目需求的理解、複雜度的估計都還停留在一個初始階段。如果在項目開發過程中不能隨着對項目的理解而改進架構，必然讓項目中的成員都按錯誤的架構去開發項目。所以，必須經常檢查項目的架構，進行必要的重構。
3.重構
有人說，都寫了這麼多了，再修改不是浪費時間嘛。他可能沒有想過，一個下午的重構可以加快以後幾個月的開發速度，這節省下來的時間是無法想象的。再者，通過重構，通常能想到更多簡單的方法來代替現有的實現，這樣的經驗，同樣可以簡化其他模塊的開發。
4.避免過度集成，讓每個模塊只做自己的事
一個常見的OA開發例子是，在業務系統中通常會有許多的審批，很多人一下子肯定會想到把審批做成一個通用的模塊。這是沒有問題的，然而通常的問題是，太多的人將審批結束後的業務處理也放到了審批模塊的業務邏輯中，其實，那些是各業務模塊自己的事，審批應該只完成審批即可，至於審批結束後怎麼辦，讓該幹這事的模塊自己去處理。
5.避免過度靈活
設計和代碼並不是越靈活越好的。一個常見的例子是，使用泛型時可以使類或者方法操作不同的對象，然而，在 JAVA 常用的 三 層架構中，如果一系列的類本來就是針對某個特定實體的操作，就沒有必要還指定爲泛型，再在使用時指定爲使用特定的實體類。這頗有畫蛇添足的感覺。
6.減少錦上添花的功能
頁面無刷新，更酷的顯示效果等等，對於業務系統來說都是些錦上添花的事，如果因爲這些而使業務界面非常複雜，給業務處理帶來一系列的問題，極端情況是業務處理無法繼續時，再漂亮的界面也是無用的。一個忠告時，僅在確保業務處理正確進行的前提下再考慮其他的。這一點有一個前提是與用戶進行必要的溝通。也就是說，JAVA實現的項目，重點在於對業務的處理上，只有很好的實現了業務處理，才能去考慮界面的美觀與用戶的視覺感官 。
7.適當拆分
這一點與 4 類似。儘量降低每個模塊的複雜度，讓腦力勞動轉化成體力勞動。一個常見的例子是，通常對某個表單都會有增加、修改、刪除和查看的功能。但是，前三種操作通常僅在某個功能點上、特定狀態和特定權限的人進行操作(也許僅在在系統中的唯一一個界面中)。而查看操作卻會分佈在項目的各個角落，如果將這四種操作都放在同一界面中，雖然可以減少界面數，但增加的卻是這一界面的複雜度，要對各種狀態、條件進行必須的判斷來進行界面元素的只讀設置，這個複雜度的增加是指數級的，而如果將查看拆分開，工作量將是線性的，就算要做10個查看界面，總比複雜度變成 10*10 要容易處理得多，況且還可以組件化。
8.與客戶保持良好的溝通
很多人都沒有注意去保持和客戶的溝通，很多架構師都認爲，只在項目的需求階段才需要和客戶有溝通和交流，這點是很不好的習慣，因爲客戶的要求會隨着時間的變化而變化，只有經常和客戶保持良好的溝通，才能在第一時間內瞭解客戶的需求變化，從而調整自己的項目架構方案，在最短的時間滿足客戶的需求。
9.項目架構與數據庫架構的聯繫
很多人都認爲，項目在開發的過程中，是不需要數據庫的，只要在內存中實現就可以了。我個人認爲，這是一種很不好的開發習慣。數據庫雖說是根據項目的具體需求而定。但一個項目在架構過程中完全不考慮數據庫的架構，那很可能就會使項目中實現的東西，在數據庫中很難記錄或者是數據庫設計很麻煩，無形中增加了項目開發的難度。並且，在項目的開發過程中不考慮數據庫，可能會使項目在掛靠數據庫後，出現部分業務邏輯的無法實現，數據的丟失等等問題。
當然，很多人的架構風格的不同，會有不同的架構見解，我的見解也不一定是正確的。希望大家可以從我的東西都學到一些東西，也希望大家可以多多交流在架構方面的看法
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/chenhuoren/archive/2009/11/30/4903900.aspx