在如下這兩篇篇文章我都或多或少強調過業務分層方面的的方法和注意事項，感興趣的可以看看:
系統設計和系統劃分有定律可循
業務拆分的思考
之前是說，現在是做。以我個人部落格為例，我的部落格最初隻是一個單體應用，但是我決定将其拆分為多個子產品，總體來說，還是一個單體war。但是性質是不一樣的。
下面進入正題:
貼圖說明:
blog-parent是父工程
blog-common主要放置工具類和其他可以複用的第三方插件或者是其他功能類
blog-entity 放置實體,通常是pojo也可以叫entity或者javabean
blog-dao 放置與資料庫互動的接口類，也就是mapper
blog-service 業務接口及其實作類
blog-web 前台展示同時如果還開發安卓應用的話，直接提供接口
blog-generator 是代碼生成器，主要應用于個人開發，提高效率用的
上述的依賴關系除了blog-generator之外，可以用思維導圖可以表示為如下所示:
不過這個結構似乎也不太合理，适用于目前而言，業務不是特别大，最好采用這種形式表示:
兩圖比較主要差別在于将blog-common放到blog-service中，因為blog-service是業務邏輯，通常業務邏輯是可以複用多個的，而像一些判斷或者是引用第三方插件，通常都在業務邏輯裡具體實作後，而web子產品中controlller直接調用即可，如果不放在blog-service中，就會出現一個問題，問題的主要凸顯就是業務邏輯複用性差，導緻很多都在controller裡面下，也就是接口裡面寫，不利于複用，而且代碼品質也會下降。
注意:
每個依賴記得都要maven install安裝到本地倉庫，否則會依賴不了，報錯。
項目github位址為:
https://github.com/youcong1996/ChallengerV.git項目結果圖如下所示:
前端模闆主要采用的是layui，其實bootstrap也有很多這樣的，大家可以在網上找找。
其實我參考了github上的不少項目還有一些小夥伴們的部落格，其實還可以再細化分為如下(這裡我還是用思維導圖表示):
這樣做的好處，主要是考慮可擴充性，前面列舉的圖一和圖二可擴充性不是特别好，當然了，如果對于是一個人開發的話，直接單體應用即可，不用拆分，如果是兩到三個人，可以按照圖一和圖二來。當然了，圖一和圖二還有一個考慮就是可讀性，公司開發人員流動性比較強，特别是中小公司，總會有人走，也總會有人來，假如你是來的人，如果看到公司所有的代碼全部在一個單體war上，而且有很多很多的com.xxxxx之類的，而且com.xxxxx下還有幾十個類，試問你會作什麼感想呢。
按照圖三的設計，以後的擴充可以是這樣：
随着業務一步一步擴大，可以将blog-web拆分為六個war,這就可能用到微服務架構了。
最後小結:
業務的擴充是一步一步慢慢來的，絕非一開始直接就業務拆分和分布式，那都是扯淡。