2.3二者區別？
在早期做三層架構的時候，大都以表來驅動，在做領域架構的時候，大都以業務邏輯來驅動，兩者的區別確實比較明顯，但到了現在，如果都以業務邏輯爲中心，那麼兩者並沒有本質區別。
攜程公司採用了第二種分層法，他們希望把分層做得極簡，也就是說，哪怕剛畢業進入公司的員工，在分層時基本上也不會亂。
相對於第一種分層法，第二種分層法簡單得多。每一個應用的代碼量都不應該很大，一旦工程變得過大，就會把它適當拆分，而不是全部放在一單體應用裏。
總之，分層越簡單，整個軟件結構就越清晰，代碼就越容易統一。
把工程做得極簡，纔有利於複製，有利於業務的快速構建，有利於規模化，使系統穩定可靠。
3.統一分層規範
以上兩種邏輯分層如何做選型？我們要回到分層的目的上來評估，我們的目標是簡單、統一、高效。所以傳統的三層架構很好的滿足了我們的需求。
而領域驅動開發，對DDD有一定的學習成本，同時對舊系統的歷史包袱，比如數據庫，我們無法做到面向領域編程，我們更多的要面向數據庫編程。
所以，當前敏捷框架比較適合想從老系統遷移的，但是有數據庫歷史包袱的團隊。
3.1減少私人定製:
減少私人通用幫助類CommonLayer的編寫，如果每一個應用中有大量相同的幫助類，則在架構層面上是有問題的。線上應用越多，則代碼重複越多。比如，每個應用都有分頁幫助類、數據庫幫助類、緩存幫助類、MQ幫助類、日誌幫助類、AOP幫助類等。
每一個應用都是特別的，都需要私人定製極少有通用的代碼，如果有，那麼應該由框架或組件專門解決。這裏框架統一放在Com.Util裏。
3.2內聚大於解耦:
內聚是指部門內有共同的目標，然後大家緊密合作。解耦是指部門間各自職責明確，然後減少不必要的連接。一個應用如同一個部門，應該有一個共同的目標和職責，然後大家緊密合作。
換句話說，應用內部應減少不必要的契約接口，減少不必要的依賴注入實現，減少不必要且代價過大的解耦。一切以簡單實用爲主，應用的價值輸出爲導向。
總之，無論採取何種分層架構，分層架構最核心的一點就是要保證各層之間職責足夠清晰，邊界足夠明顯，讓人看到架構圖後就能看懂整個架構。