為了將業務規則從介面和資料庫中剝離出來，通常的做法是抽象出乙個業務邏輯層出來，專門負責對業務邏輯進行處理。一般多採用三層結構，既表現層，業務層和資料層。
當開發人員在以前的兩層結構中痛苦煎熬了很長一段時間，突然看到了三層結構的解決方案的時候，一般會有終於找到了救世主的感覺。但是這種感覺往往會導致掉到另外乙個同樣恐怖的陷阱「過度設計」中。在我以前曾經供職的一家公司，以前都是把sql語句直接寫在aspx頁面的，後來在讀到了一些關於多層結構方面的資料之後，一下子又把整個系統分成了：表現層（aspx）、介面外觀層（if），業務外觀層（bf），資料訪問外觀層（daf），資料訪問層（da）和資料訪問元件（sqlhelper）。但是我並沒有吸取教訓，導致後來也犯了同樣的錯誤。
犯錯誤的原因有很多，不過主要是因為沒有乙個比較明確的如何分層的指導性原則。假如說我們分層的原則是為了抽象邏輯，分三層的原因是要讓業務邏輯和介面及資料庫解除耦合，那麼如果按照這個分層原則，我把邏輯重新歸類更加細的分為四層、五層、六層行不行呢？如果不行，那是什麼原因不行呢？在沒有正確的原則指導下，分層技巧很容易被濫用，導致分出許多沒有必要的層出來。無端的增加了開發和維護成本，以及更重要的是增加了重構的代價，降低了團隊的敏捷能力。
物件導向架構設計大師martin fowler在介紹如何設計分布式系統的時候曾說過：分布式系統的設計原則的第一條是，不要使用分布式。他的意思當然不是說要絕對禁止使用分布式設計，而是勸導人們盡量把問題簡單化。能不分布式設計的，就不要分布式設計。
我套用他的這句話提出我對分層的感受就是：多層結構系統的設計原則第一條是，不要使用多層結構。
當然我的意思也並不是說層數越少就越好，而是希望你能清醒的認識到增加層數會增加結構的複雜性，不要輕易的作出分層的決定，一定要到感覺必須要增加一層才能解決問題的時候，再來決定增加一層。
過多的層次除了會給系統帶來不必要的複雜性外，還會影響你的系統結構設計。如果你打算採用物件導向的領域模型來設計系統的話，在業務系統內的分層會給物件導向系統的設計帶來很多麻煩，會很容易走回到事務指令碼的老路上去。關於這一點，我在物件導向系統設計經驗談
這篇blog裡詳細的談到過，這裡就不再贅述。
下圖是我們最終定型的應用系統結構層次：
總結一下：
建立乙個完全物件導向建模的領域模型層，讓這個層盡量處理多的業務邏輯。其它層盡可能的薄一點，把業務邏輯都轉移到領域模型層中。
ui盡可能和領域模型貼近一點，中間不要經過太多中轉，物理邊界也盡可能的少。
業務物件只能有一套，也就是領域模型。只要出了領域模型層，外面全部是零散資料，沒有物件的概念。
只有在領域模型層才可以處理物件。
如果一定要分布式。全部用簡單資料型別通過介面訪問領域模型。
這個分層結構其實是經歷了多次精簡完成的，所有的感觸都歸結為一句話：不要過度設計，簡單就是美。
跳槽經驗談
每年年初跳槽最多，跳槽是一門學問，也是一種策略。跳槽並不意味著你就能夠取得職業的成功，當面臨跳槽時，如何順利地完成跳槽，從而取得職業的成功呢？以下是一些切身體會，值得大家參考。1 不要指望會一下子能夠跳到多麼好的公司，絕大多數公司都乙個樣子。比如用友 金蝶 亞信 神馬這些公司，其實基本上乙個樣子。2...
程式設計經驗談
不知不覺做軟體已經做了十年，有成功的喜悅，也有失敗的痛苦，但總不敢稱自己是高手，因為和我心目中真正的高手們比起來，還差的太遠。世界上並沒有成為高手的捷徑，但一些基本原則是可以遵循的。紮實的基礎。資料結構 離散數學 編譯原理，這些是所有電腦科學的基礎，如果不掌握他們，很難寫出高水平的程式。據我的觀察，...
程式設計經驗談
1 萬丈高樓平地起。基礎是一切技能的本源，只有打好基礎，才能談得上提高，才能談得上有靈感，有突破。2 書上學的終覺淺。程式設計是一門實踐性極強的工作，只有通過不斷的程式設計實踐，才能積累程式設計經驗 提高程式設計能力，才能真正成為一名合格的開發者。3 曲徑通幽處。學習程式設計的道路是充滿艱辛的，漫長...