公司分層思想的演化歷程

分層思想的演化是根據實際業務的需求不斷改進而來的，下面就來討論一下咱們公司分層架構思想的演化歷程：

第一階段【大雜燴】

一開始咱們作項目不會考慮不少東西直接一個項目搞定。

不論是後臺管理系統，前端業務，仍是用戶登錄系統所有都放到了一個項目中去作。

第二階段【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層的項目。

結合咱們老大的博客相信你會理解的更透徹

基於分佈式、服務化的maven項目文件規劃