越來越多人開始使用Java，但是他們大多數人沒有做好足夠的思想準備(沒有接受OO思想體系相關培訓)，以致不能很好駕馭Java專案，甚至導致開發後的Java系統性能緩慢甚至經常當機。很多人覺得這是Java複雜導致，其實根本原因在於:我們原先掌握的關於軟體知識(OO方面)不是太貧乏就是不恰當，存在認識上和方法上的誤區。

　　軟體的生命性

　　軟體是有生命的，這可能是老調重彈了，但是因為它事關分層架構的原由，反覆強調都不過分。

　　一個有生命的軟體首先必須有一個靈活可擴充套件的基礎架構，其次才是完整的功能。

　　目前很多人對軟體的思想還是焦點落在後者:完整的功能，覺得一個軟體功能越完整越好，其實關鍵還是架構的靈活性，就是前者，基礎架構好，功能新增只是時間和工作量問題，但是如果架構不好，功能再完整，也不可能包括未來所有功能，軟體是有生命的，在未來成長時，更多功能需要加入，但是因為基礎架構不靈活不能方便加入，死路一條。

　　正因為普通人對軟體存在短視誤區，對功能追求高於基礎架構，很多吃了虧的老程式設計師就此離開軟體行業，帶走寶貴的失敗經驗，新的盲目的年輕程式設計師還是使用老的思維往前衝。其實很多國外免費開源框架如ofbiz compiere和slide也存在這方面陷阱，貌似非常符合胃口，其實類似國內那些幾百元的盜版軟體，擴充套件性以及持續發展性嚴重不足。

　　那麼選擇現在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基礎架構打好了呢?其實還不盡然，關鍵還是取決於你如何使用這些框架來搭建你的業務系統。

　　儲存過程和複雜SQL語句的陷阱

　　首先談談儲存過程使用的誤區，使用儲存過程架構的人以為可以解決效能問題，其實它正是導致效能問題的罪魁禍首之一，打個比喻:如果一個人頻臨死亡，打一針可以讓其延長半年，但是打了這針，其他所有醫療方案就全部失效，請問你會使用這種短視方案嗎?

　　為什麼這樣說呢?如果儲存過程都封裝了業務過程，那麼執行負載都集中在資料庫端，要中間J2EE應用伺服器幹什麼?要中間伺服器的分散式計算和叢集能力做什麼?只能回到過去集中式資料庫主機時代。現在軟體都是面向網際網路的，不象過去那樣侷限在一個小區域網，多使用者併發訪問量都是無法確定和衡量，依靠一臺資料庫主機顯然是不能夠承受這樣惡劣的使用者訪問環境的。(當然搞資料庫叢集也只是五十步和百步的區別)。

　　從分層角度來看，現在三層架構:表現層、業務層和持久層，三個層次應該分割明顯，職責分明:持久層職責持久化儲存業務模型物件，業務層對持久層的呼叫只是幫助我們啟用曾經委託其保管的物件，所以，不能因為持久層是保管者，我們就以其為核心圍繞其程式設計，除了要求其歸還模型物件外，還要求其做其做複雜的業務組合。打個比喻:你在火車站將水果和盤子兩個物件委託保管處保管，過了兩天來取時，你還要求保管處將水果去皮切成塊，放在盤子裡，做成水果盤給你，合理嗎?

　　上面是談過分依賴持久層的一個現象，還有一個正好相反現象，持久層散發出來，開始擠佔業務層，腐蝕業務層，整個業務層到處看見的是資料表的影子(包括資料表的欄位)，而不是業務物件。這樣程式設計師應該多看看OO經典PoEAA。PoEAA 認為除了持久層，不應該在其他地方看到資料表或表字段名。

　　當然適量使用儲存過程，使用資料庫優點也是允許的。按照Evans DDD理論，可以將SQL語句和儲存過程作為規則Specification一部分。

　　Hibernate等ORM問題

　　現在使用Hibernate人也不少，但是他們發現Hibernate效能緩慢，所以尋求解決方案，其實並不是 Hibernate效能緩慢，而是我們使用方式發生錯誤:

　　“最近本人正搞一個專案，專案中我們用到了struts1.2+hibernate3, 由於關係複雜表和表之間的關係很多，在很多地方把lazy都設定false，所以導致資料一載入很慢，而且查詢一條資料更是非常的慢。”

　　Hibernate是一個基於物件模型持久化的技術，因此，關鍵是我們需要設計出高質量的物件模型，遵循DDD領域建模原則，減少降低關聯，通過分層等有效辦法處理關聯。如果採取圍繞資料表進行設計程式設計，加上表之間關係複雜(沒有科學方法處理、偵察或減少這些關係)，必然導致 系統執行緩慢，其實同樣問題也適用於當初對EJB的實體Bean的CMP抱怨上，實體Bean是Domain Model持久化，如果不首先設計Domain Model，而是設計資料表，和持久化工具設計目標背道而馳，能不出問題嗎?關於這個問題N多年就在Jdon爭論過。

　　這裡同樣延伸出另外一個問題:資料庫設計問題，資料庫是否需要在專案開始設計?

　　如果我們進行資料庫設計，那麼就產生了一系列問題:當我們使用Hibernate實現持久儲存時，必須考慮事先設計好的資料庫表結構以及他們的關係如何和業務物件實現對映，這實際上是非常難實現的，這也是很多人覺得使用ORM框架棘手根本原因所在。

　　當然，也有腦力相當發達的人可以 實現，但是這種圍繞資料庫實現對映的結果必然扭曲業務物件，這類似於兩個板塊(資料表和業務物件)相撞，必然產生地震，地震的結果是兩敗俱傷， 軟的一方吃虧，業務物件是程式碼，相當於資料表結構，屬於軟的一方，最後導致業務物件變成資料傳輸物件DTO, DTO滿天飛，效能和維護問題隨之而來。

　　領域建模解決了上述眾多不協調問題，特別是ORM痛苦使用問題，關於ORM/Hibernate使用還是那句老話:如果你不掌握領域建模方法，那麼就不要用Hibernate，對於這個層次的你:也許No ORM 更是一個簡單之道: No ORM: The simplest solution

　　Spring分層矛盾問題

　　Spring是以挑戰EJB面貌出現，其本身擁有的強大元件定製功能是優點，但是存在實戰的一些問題，Spring作為業務層框架，不支援業務層Session 功能。

　　具體舉例如下:當我們實現購物車之類業務功能時，需要將購物場合儲存到Session中，由於業務層沒有方便的Session支援，我們只得將購物車儲存到 HttpSession，而HttpSession只有通過HttpRequest才能獲得，再因為在Spring業務層容器中是無法訪問到HttpRequest這個物件的，所以， 最後我們只能將“購物車儲存到HttpSession”這個功能放在表現層中實現，而這個功能明顯應該屬於業務層功能，這就導致我們的Java專案層次混亂，維護性差。 違背了使用Spring和分層架構最初目的。

　　領域驅動設計DDD

　　現在回到我們討論的重點上來，分層架構是我們使用Java的根本原因之一，域建模專家Eric Evans在他的“Domain Model Design”一書中開篇首先強調的是分層架構，整個DDD理論實際是告訴我們如何使用模型物件oo技術和分層架構來設計實現一個Java專案。

　　我們現在很多人知道Java專案基本有三層:表現層　業務層和持久層，當我們執著於討論各層框架如何選擇之時，實際上我們真正的專案開發工作還沒有開始， 就是我們選定了某種框架的組合(如Struts+Spring+Hibernate或Struts+EJB或Struts+JdonFramework)，我們還沒有意識到業務層工作還需要大量工作，DDD提供了在業務層中再劃分新的層次思想，如領域層和服務層，甚至再細分為作業層、能力層、策略層等等。通過層次細化方式達到複雜軟體的鬆耦合。DDD提供瞭如何細分層次的方式

　　當我們將精力花費在架構技術層面的討論和研究上時，我們可能忘記以何種依據選擇這些架構技術?選擇標準是什麼?領域驅動設計DDD 回答了這樣的問題，DDD會告訴你如果一個框架不能協助你實現分層架構，那就拋棄它，同時，DDD也指出選擇框架的考慮目的，使得你不會 人云亦云，陷入複雜的技術細節迷霧中，迷失了架構選擇的根本方向。

　　現在也有些人誤以為DDD是一種新的理論，其實DDD和設計模式一樣，不是一種新的理論，而是實戰經驗的總結，它將前人 使用面向模型設計的方法經驗提煉出來，供後來者學習，以便迅速找到駕馭我們軟體專案的根本之道。

　　現在Evans　DDD概念很火，因為它將著名的PoEAA進行了具化，實現了PoEAA可操作性，這也是MF大力推崇的原因。最近(8月8日)一位老外部落格上用微軟的.NET架構和Evans DDD比較的文章:比較了微軟的三層服務應用架構[Microsoft TLSA]和Evans DDD的架構， 使用Microsoft .NET Pet Shop 4為例子，解釋兩個目標的區別，並且表明微軟是如何在案例中更好地實現支援後者。這篇文章幫助哪些.NET平臺上有域設計知識的人實現更好地提高。

　　另外一本關於.NET的DDD書籍也已經出版，這些都說明Evans DDD這把火已經燒到.NET領域，當然DDD在Java領域生根開花多年，Evans的DDD書籍就是以Java為例子的，筆者板橋里人也率先在2005年推出DDD框架JdonFramework 1.3版本，這些都說明，Java在整個軟體業先進思想的實踐上總是領先一步。