Spring mvc 做久了其實挺無聊的，一直在業務層自旋，不大好突破到新的境界，這其實和業務規模和用戶數量以及應用場景都有關系，當然還要考慮上線求穩的心理，ok 話回正題，在spring mvc的時代整個項目作為一個整體放在容器中對外提供服務。

這個是讀過下方參考文章的模塊劃分圖 之後產生的思考，其實讀完這個之後也觸發了我之前很多關於這些的想法，寫出來算是自己沈澱下，不全後續再有靈感可以在補充。

原圖如下：

經典的三層架構：

1. 基礎層：dao, 幫助類，IO讀寫，資源加載等一些基礎設施，他們作為整個系統最基礎的模塊可以組合成業務層和服務層

2.業務層和服務層：典型的就是 service,這裏承載更多的是業務的實現，資源的組合調度，事務實現，等等，這裏是整個系統最核心的地方，下面整合底層dao以及事務，根據業務和場景靈活的把業務邏輯使用底層的基礎單元拼接組合起來，上面為表現層提供具體的業務處理邏輯

3.表現層：接受外部的請求，並把調用對應的service操作具體業務，把最終結果反饋給調用者或是用戶

四層架構，在基礎層基礎之上還可以在分出一層：領域層，基礎層還是提供基本的數據操作和IO與網絡操作，不過領域層對基礎層再來一次封裝和整合，目的也是方便整合底層資源方便service層調用，簡化業務層和基礎層的復雜依賴

靜態業務對象：

ViewObject : VO 界面展示用到的數據對象

DomainObject: DO 領域層對象，一般可以簡約的理解為java bean對象，從業務中抽取的基本模型類

BussinessObject: BO 業務對象一般也在service業務層，如果DO不能完全表達，可以使用BO獲取更多信息的表達，並且還可以封裝重用DO中的實體信息

PersistantObject: PO 持久存儲對象，一般作用於dao層，和數據庫實體對應

DataTransferObject : DTO 數據傳遞對象，用於封裝參數，數據中轉會，重構過程方法列表會用到

動態處理對象：

Controller 控制器, Manager 管理類, Service 服務類, Repository, DAO 數據源, Client 客戶端, Dispather 轉發器, Handler 處理器, Interceptor 攔截器

Helper,Utils 幫助類

動態的配置文件與屬性：

一些經常用到的開關和閾值一定要寫在配置文件中，或有配置中心可以下發，不要在程序中寫死，而且要有對相應的刷新機制api接口，調用後強制刷新配置參數

常用的比如：

• 活動的開始結束日期
• 業務中的最大值，限制值等閾值
• 外界的URI: 文件上傳地址，靜態資源位置，等等
• .....等等一切可以借鑒Ioc理念抽取出來的配置變量

其實如果在往下還可以在細分：對外接口層, 接入層, 持久層... 大的框架會描述一個思考的方向，根據業務和場景的不同可能會有不同的要求，項目不同階段也會面臨變化，這及時軟件給人帶來困惑的地方，也是讓人欣喜的地方，到底什麽樣的架構才是好的架構，隨著時間和叠代的前進你會發現不同時間都有不同的考慮和考量，任何時候都沒有完美的方案，可能會因為排期和deanline的壓力或是行政績效的壓力選擇一些妥協的方案或是自己懶惰沒有做出相對較好的方案，但是你會發現永遠都沒法完美，就像極限的概念你可以無限接近但就是無法達到....

參考文章：http://ifeve.com/am-hierarchy/

軟件分層設計與常見業務對象