來源：www.cnblogs.com/wangsen/p/5052068.html
分層思想的演化是根據實際業務的需求不斷改進而來的，下面就來討論一下我們公司分層架構思想的演化歷程：
第一階段【大雜燴】
一開始我們做項目不會考慮很多東西直接一個項目搞定。
不管是後臺管理系統，前端業務，還是用戶登陸系統全部都放到了一個項目中去做。
第二階段【webapp層】
按照上面的做法會遇到一個問題，如果其中用戶登錄出現錯誤就會全部不能夠訪問。
後來就要求將前端的業務，後臺管理系統，以及用戶登錄要求分佈，這個時候就採取分佈式啦。
按照上面的做法的確可以實現三個不同的應用相互不受影響，即使後臺掛啦，前臺業務和登錄也可以使用。
到目前爲止webapp層就浮現啦，給該層的定義是：
爲互聯網用戶提供對外服務，在這層的每一個項目都有自己不被共享的業務。
第三階段【business層】
在實際應用中我們發現一個問題：
Aweb應用和Bweb應用中存在公用業務流程，怎麼處理？
如圖：
我們的做法是將a業務流程抽取出來。
如圖：
比如：我們項目中課程項目和電視端視頻課程項目都會使用訂單相關的業務，那麼我們的做法是將公用的業務單獨創建一個項目（jar包）的形式，讓web應用引用就行啦，當然這不是唯一的解決方案。
如圖：
其實到這裏我們另一個分層就出來啦：business層
給該層的定義：該層的項目必須是一個提供“共享”業務流程。
第四階段【base層】
但是這麼劃分項目也引發了另外一個問題：
A business項目和B business同時共用一個資源的時候我們怎麼做？？
比如：訂單business項目和單點登錄business項目都需要使用到用戶相關的服務，我們不可能每一個business項目都寫一套相同的代碼。
我的做法是將用戶提供的相關服務單獨作爲一個項目，如：
其他項目可以引用用戶提供服務的項目，如：
這樣我們就已經解決了多個business項目共享同一份資源的問題，避免了每個應用都重複造輪子。
其實到這裏我們的另外一個分層就出現了：base層
我們給該層的定義是：該層中的項目有且只能代表一個真實存在而且能獨立存在的核心實體對應的業務。
詳細解釋一下：
真實存在：可以用一個具體的客觀物體承載的，比較聚合的概念。比如：用戶，課程，試題。
不是說一個用戶實體就是對應一個base項目，而是我們在對用戶進行面向對象分析和抽象的時候抽取出來的所有相關的
對象都屬於這個base項目。
如：
這裏的實體全部是與用戶這個抽象概念有關的，比如：學生實體，老師實體，用戶詳細實體，用戶實體等等。
第五階段【core層】
在開發的過程中，我們發現不管是webapp層，business層還是base層都會用到一些和業務無關的服務。
比如：數據庫持久，redis緩存,http封裝，通用工具等。
我們根據這些服務的特徵單獨出去來多個項目，我們稱之爲這層爲core層:
這層的定義：
這層的項目與業務沒有關聯的，只提供基礎能力。
第六階段【使用】
到現在webapp層，business層，base層以及core層已經劃分完畢。
那麼我們是如何使用這些的呢？？
使用步驟如下：
分析一下，這個產品是否要對用戶獨立提供服務，不受其他的產品影響。如果要，則新建web項目。
分析一下，這個產品有沒有哪些業務是準備被其他產品使用的，即在其他產品的界面有沒有體現本產品。
如果有，分析一下這些公用的業務，有沒有包含一個流程性，即它的業務在組合其他已有base項目。如果有，新建一個business項目
分析一下，這個產品有沒有可以獨立存在，不依賴於任何其他服務的業務。如果有，新建一個base項目。
當實現這些編碼時，如果有遇到一些與業務無關的，只提供能力的，則新建一個core項目。
注意：
core層的任何項目其他層的項目都可以直接使用。
同一層的項目可以相互引用。
webapp層的項目不能相互引用，如果有想使用其他的項目服務，可以將那個服務下層到business層中實現。
上層可以跨層依賴下層，比如：webapp層中的項目不僅僅可以引用business層的項目也可以直接引用base層的項目。
PS：如果覺得我的分享不錯，歡迎大家隨手點贊、轉發。