三層架構是我們設計複雜的企業應用的乙個最基本的分層結構了。下面試圖闡述一下三層架構的基本特性。並且結合易經的知識來幫助我們理清思路，更好地看到三層架構的本質。
這裡要向大家推薦martin fowler寫的《企業應用架構模式》，裡面對三層架構有很清楚的解釋了。
在分解複雜的軟體系統時，我們常用的技術之一就是分層。計算機世界中大量使用分層，比如說從應用軟體、作業系統到硬體層；另外還有大家都熟悉的tcp/ip架構。分層架構中最困難的問題是決定建立哪些層次以及每一層的職責是什麼。
我們這裡著重要分析的是三層架構。三層架構分為：表現層、領域層、資料來源層。
表現層提供服務，顯示資訊，處理使用者請求，http請求，命令列呼叫，批處理api。
領域層包含業務邏輯，系統中真正的核心。
資料來源層處理與資料庫、訊息系統、事務管理器及其他軟體包通訊。
提一下，這裡的分層指的是邏輯上的分層，和系統部署在幾台機器上並沒有關係。另外還存在著物理上的分離，這個就不再討論範圍之內了，強調一下避免有人混淆。
接下來說重點。《道德經》中的一句話「道生一，一生二，二生三，三生萬物」，這個觀點是從《易經》中來的，所以借用這句話來引出「三才」的概念。首先從無生有，出來那個一，叫做太極。太極生兩儀，一分為二有了陰陽。陰陽調和出來三，於是有了不陰不陽的東西「和」。
大家肯定聽過盤古開天地的傳說，盤古一把斧頭劈過去，清的上公升變成了天，濁的下降變成了地，處於清濁之間的就成了天地萬物。也就是說「三才」指的就是天、地、人。分別代表的是清、濁、和。
可以將軟體中的三層架構用三才的角度來分析。表現層為天，資料層為地，領域層為人，這樣三層架構中的每一層就有了獨特的屬性與含義。
我們的軟體從本質上來說都是在處理資料，資料對於使用者來說就是資訊、是價值。
上次參加乙個架構師培訓的時候，老師給我們舉了乙個例子。三峽工程需要做乙個專案，這個肥差當然有很多軟體公司搶著要。但其中有一家軟體公司曾經給三峽工程做資料庫，他們掌握著所有的資料資訊。這樣一來，其他公司的機會就微乎其微了。整個資料都掌握在別人手裡，再去和他競爭是沒有任何意思的。最終的結果也是這家掌握了資料主動權的公司拿到了專案。
現在國內有不少軟體公司發展得不錯，尤其是在做行業軟體的時候。一些有實力的人都爭先恐後地提出標準，就是些資料標準。如果這樣的標準在行業內得到認可的話，這家公司可以說是立於不敗之地了。由此可見資料的重要。
資料層為地，它具有大地「厚德載物」的特性。它是整個軟體的立命所在，這層的好壞直接影響到整個軟體體系。
表現層是使用者直接接觸的軟體模組。使用者是上帝，今後面向服務的產業模式更好地突出了這句話的含義。
有很多人專門研究人機互動，他們的工作就是研究表現層的設計了。
敏捷是非常好的思想。其中敏捷的核心是迭代，迭代的核心是使用者。敏捷之所以能更加成功，關鍵點就在於它把握住了軟體中的核心——使用者。表現層直接和使用者打交道，所以它的主要職責就是滿足使用者的需求，將功能以最合適的方式展現給使用者。
表現層為天。《易經》中說「天尊地卑」。這有兩種含義，一是，天高高在上，我們需要用尊重的態度去對待，一切都是使用者至上；另外天為什麼尊貴，那是因為它離我們最遠，說地卑並不是說他不重要，而是說地離我們最近也最親近。使用者離我們是非常遠的，當我們注意到這點後在行動上就要有所不同了，比如說xp中提倡的「客戶參與」就表明xp大師們知道這點。
在學校或者剛進入公司的時候，寫程式更加關注介面的實現，一看到漂亮的介面就會去研究它是怎麼實現的，然後迫不及待地想加到自己的程式中。
等到真正成為乙個職業的程式設計師後才會明白，軟體中的核心不在介面，其實也不在資料層，而是在領域層。領域層中包含的是絕大多數使用者需求的實現。單憑這點，領域層在軟體中的位置就不言而喻了。
領域層是人，人是天地之間的萬物之靈，是陰陽調和的產物。為什麼說領域層是人呢？做人有一點非常關鍵——變通。人是一切社會關係的總和，如果乙個人不懂得變通，那麼他是很難在社會上生存下去的。
領域層同樣也需要有變通的性質。使用者需求變化，我們的軟體就必須要改，這個叫做變。變完之後我們還需要有大量的時間來維護，怎樣降低維護成本呢，需要我們有乙個良好的設計，這個叫做通。我們不管是在最初設計領域層，還是以後不斷維護它的時候都需要注意「變通」。
不變不通，那這個軟體基本上就廢掉了。很多時候我們的軟體需要做新版本，當然一方面是想收使用者的公升級費，另外更要緊的是因為以前的版本「不變不通」了。使用者的新需求加不上去，維護成本驚人。算了，新做乙個吧。如果我們在維護的時候也能注意變通的話，軟體的生命週期應該會長得多。
領域層是「人」，人是萬物之靈，真是「萬物之靈最難為」。
陰陽變化乃生萬物。任何事物中都有陰陽，那就看我們怎麼分析了。
拿陰陽之說來闡述軟體，我好像是有史以來第一人，沒有見過其他的資料，如果有朋友發現在這篇文章之前還有高人這樣做過，懇請告知，我一定要去拜讀。
對於軟體來說，有兩端需要我們注意。乙個是使用者、乙個是資料（二進位制的、文字的、的、資料庫的）。所有的軟體都在做同樣一件事情，沒有第二件。軟體都在處理使用者和資料的關係。
使用者為幹（陽）、資料為坤（陰）。我們的軟體就是在陰陽之間調和。將使用者和冷冰冰的資料聯絡起來就是我們做軟體的宗旨。
前面介紹了三層架構。但不是所有的軟體都需要三層。拿到乙個系統，二話不說就來三層，這樣做是非常錯誤的。
有的軟體特別簡單，一層就搞定了，還分什麼，徒增麻煩。有的軟體用bs結構搞定的非常漂亮，沒有其他的需求的話非搞出乙個第三層也是虧本的買賣。
對於複雜的軟體來說，三層就是乙個比較好的解決方法了。另外還有其他的一些分層方式。
brown提出的五層，表現層、控制層、領域層、資料對映層、資料來源層。
core j2ee的五層，客戶層、表現層、業務層、整合層、資源層。
microsoft的dna架構，表現層，業務層，資料訪問層。
還有很多，就不一一舉例了。
大家看看上面這些分層架構，其實不管多麼複雜，都是陰陽（使用者到資料）的相互調和，所以「二生三，三生萬物」。當我們把根本的東西掌握住之後，不管萬物怎樣變化，都是可以被我們認知、掌握的。
ps：這篇文章寫出來後非常擔心網友們覺得寫得太膚淺。萬事開頭難，有了這個想法我一定會堅持不懈地研究下去的。現在只好請諸位忍耐忍耐，多看看在下的幾篇拙文。衷心感謝那些批評的、給我建議的朋友們。以後也請大家多多批評指正。
trackback:
八卦一下模型驗證 三
csdn的大大們啊，求求你們了啊。修復這坨不能自動上傳的錯誤啊。好像已經三個月了啊。圖多的時候發文章真地很痛苦啊。orz orz orz 準備八卦edmund等人演算法時才想起，人1986年成名作是討論用ctl computational tree logic 作規範語言的模型驗證演算法，而第一篇八...
八卦一下模型驗證 三
csdn的大大們啊，求求你們了啊。修復這坨不能自動上傳的錯誤啊。好像已經三個月了啊。圖多的時候發文章真地很痛苦啊。orz orz orz 準備八卦edmund等人演算法時才想起，人1986年成名作是討論用ctl computational tree logic 作規範語言的模型驗證演算法，而第一篇八...
八卦一下g9的八卦
八卦一下g9的八卦 早就想八卦一下g9老大 的技術八卦 了。國內技術社群能把技術和八卦整合得如此天衣無縫的，就我所知，僅此一家，別無分號。有時我就想不通乙個問題，為什麼這哥們文章中的八卦總是那麼源源不絕，信手拈來呢？我暗地裡琢磨這老大肯定私下有乙個小本本，上面的名人技術八卦按字母索引按年代索引按語言...