在剛工作不久時就對代碼的分層結構感到疑問，我對分層的理解主要分爲三個階段：
- 階段一：比如就MVC三層結構各層之間對象的對應關係及轉換哪些是有必要的，哪些是沒有必要的，代碼結構爲什麼要三層？如果三層不滿足怎麼辦，此時要不要類似像阿里規範中加一層Manager層（後來加了但不知道爲什麼加）？當初沒有一個有經驗的架構師來帶，對這塊的理解走偏了。
- 階段二：自從有一天理解了使用DDD思想來對業務對象建模，才明白阿里規範中加一層Manager層的作用，但問題還是來了，有些問題還是弄不明白，比如事務放在哪一層，放在領域層還是應用層？什麼是領域服務，怎麼劃定領域對象的職責？
- 階段三：攻克營銷系統“互動營銷領域建模及實踐”後，階段二的幾個問題也清晰了，也基本對代碼的分層結構有了自己的理解。
基於現階段的理解，總結出了個人理解的業務系統的分層結構，如下圖：
參考上面的分層結構，有以下幾點可以明確：
第一點：阿里規範中的Manager層本質上就是領域層。
第二點：事務放在應用層是最合適的，應用層涉及到業務的一個完整的編排，即一個事務的完整流程。若領域層需要事務怎麼辦？比如一個領域聚合對象涉及到多個對象組合，這裏可以看作一個子事務來保證領域對象的一致性。
第三點：層與層的依賴關係是單向的，上層可以直接使用或操作下層元素，若下層需要與上層進行通信，可使用回調模式或觀察者模式實現。
第四點：DDD提倡富領域模型，儘量將業務邏輯歸屬到領域對象上，實在無法歸屬的部分要設計成領域服務。另外，領域服務會對多個實體或值對象進行組裝和編排。