領域模型驅動開發(2)-工程結構的調整

#一. 背景#
目前很多的業務程式碼存在以下問題

1. bean的建立太隨意，基本就是一個需求一些對應的dto,vo，query bean。

2. 不同開發者對於同一個領域的東西有不同的bean，同一個開發者對於相同邏輯的bean，在經過2月+的時間，自己又定義出了一個差不多的bean -> 職責分散

3. 不同開發者對於某塊相同業務的邏輯校驗放在了不同的service中 ->程式碼邏輯重複

4. 不同的後端/前端對接時，相同概念的命名存在差異，導致後面重構時資料訪問沉澱到manager層，上層呼叫的時候處理case有問題

5. DTO型別的bean重構過程中根本不知道哪些是可以為Null，哪些不可以
   根本沒有上下文/邊界的概念，比如說模組A會和模組B有互動，模組C會和模組B有互動，通常在DB儲存時只會存關聯id，然後需要去取對應的名稱，其他屬性資訊。
   這些資訊的獲取，有些開發在manager層操作，然後將屬性定義到了模組A相關的DTO中，有些放在了service層做，對於模組B的有效性校驗，也是在不同的service中

#二. 工程架構圖演進#

現狀##

目前的系統結構圖通常下面這樣

1. 四層 controller/service/manager/mapper

2. 不可以同級呼叫

3. 上級可以知曉下級，下級不可知曉上級，也就是bean的轉化放在上級

這個分層結構和領域模型對應一下就會發現有些問題

1. 資源服務層repository是面向DB程式設計

2. service層是面向前端頁面程式設計。

這樣對於某一塊的業務，還是沒有將邏輯抽象到一起,也就不可避免的邏輯冗餘

##改進##

1. service層只能呼叫自己領域的manager

2. 增加一層Facade層，專門處理與其他領域的互動(如果業務還沒有這麼複雜，加上層級太多影響開發效率，
   可以採用FacadeXXXService來標識這個類專門處理與其他領域的互動)
   這樣調整以後結構清晰了許多了，manager層只處理自己領域的資料/快取，service層處理自己領域的業務。與外界互動都在自己Facade層。

雖然這些改造都只是包結構的調整，但對於一個持續迭代的多人專案開發，帶來的好處是能夠快速瞭解某一塊業務，當新人寫這塊業務的時候，能夠寫在對應的模組，能夠利用已經寫好的邏輯/bean.

#三. 領域識別#
領域演進
. 明確的領域
這些領域概念比較清晰，在業界比較通用在一開始就能明確，比如使用者，商品，訂單

演變的領域

有些業務是不斷演進的，一個領域也會裂表為多個領域，比如訂單和支付。
也有一些比較模糊的領域區分，比如商品清單這邊有個清單業務，將商品新增到清單，就是一個collection，DB的設計也就是關聯id而已，它能夠劃分到商品領域嗎，不能，因為它不屬於商品，沒有它不影響商品業務。
清單只是一個展示商品的地方。那他能成為一個單獨的領域，也很勉強，因為它的概念比較單薄，可以抽象出來的東西比較少，對於這類的問題，建議是在類級別做區分，當它的概念不斷增加，領域不斷豐富時，抽出到單獨的包，作為一個新的領域

#四. 領域模型與微服務化#
做上面結構的調整，除了能夠提供程式碼規範性，另外一個好處就是做減小微服務化的改造代價。因為邊界清晰，與其他業務的互動清晰。比如你有一個工程，規劃了6個領域模組，當某個領域模組發展足夠大，可以遷移出去作為一個獨立的微服務部署，這時候只需要將它對應的service,manager包，以及對於的bean遷出即可。其他服務與它的互動可以由service改成soa呼叫

潛在的問題
目前的領域物件還是不夠豐富
當領域物件多了，相同的編排/組合領域物件也可以成為一個獨立的領域上下文，這時候如何定義這類領域