《領域驅動設計》乾貨整理

Repository設計思路

像模塊化系統、模塊化代碼一樣，模塊化資料庫中的表。使得每個模塊之間有清晰的界限。

Repository代碼設計

1. 可以將Repository理解為一個集合（這裡的集合更偏重於是Collection，而不是Set），它包括了對存儲對象基本的增刪改查（CURD）功能。同時，Repository還包括滿足領域層的一些特定的功能（註：在Repository中包括這些功能是合理的，首先這些功能是底層設施應該提供給上層的領域層的，其次在這裡實現可以更好的利用底層設施的特點來進行性能優化）（註：在一般領域驅動設計的項目中分層都是上層依賴下層，這裡的設計卻更偏向於下層基礎設施層依賴於上層領域層。應該可以發現，這裡Respository的需要包含的功能都是由上層領域層需要什麼決定的，而不是由下層基礎設計層能提供什麼決定的。筆記認為這樣的設計其實是更合理的，《Clean Architecture》一書的作者也與筆者持有相同的觀點。這個問題的講述可以單獨寫一篇博客，再這篇文章里不再細究）。
2. 不是每張表都需要有一個Repository(在Mybatis中aka：Mapper）與之對應，更準確的說：應該將資料庫中的全部表表聚積到幾個根對象上（聚積方法後面講），這個根對象應該有Repository，而聚積在這個根上的對象不應該有Repository。對這些非根對象的訪問，應該通過於根對象的對象關係來實現。
3. （註：和第一條緊密相關，我暫時沒有想清楚他倆之間的聯繫）正確的組合搜索於關聯。搜索，即通過給Repository傳遞查詢參數來獲取對象；關聯，即通過要訪問對象與通過搜索得到的對象的關聯來獲取對象。
4. Repository應該是一個介面，將其實現與領域層的需求解耦。同時，方便測試時進行插樁和mock。
5. 雖然通過介面解耦了Repository與領域層，但是即便是領域層的開發人員，也應該清楚Repository的實現。避免出現性能問題。
6. Repository不插手事務，將事務管理交由上層領域層和應用層管理。
7. Repository應該讓客戶感覺到那些對象就好像駐留再記憶體中一樣。
8. 根是Aggregate中包含的一個特定的Entity。在一個Aggregate中，根是唯一允許外部對象保持對它的引用的元素，而邊間內部的對象之間則可以互相引用。

資料庫模式（database schema）設計

筆者認為的書中不嚴謹的地方

1. P104，書中寫道：

當然，如果在Java中查詢所返回的對象是集合時，客戶不管怎樣都要執行這樣的轉換。

Java1.4添加了泛型之後，返回集合時，不再需要用戶進行強制類型轉換。作者寫書時，Java1.4應該還沒有發佈，所以這樣描述並沒有錯誤。但是，這可能給後來的讀者造成一些困惑。

TODO

1. P102頁中提到的一種靈活的、聲明式的表示搜索標準的方法於Mybatis中的Example的概念有點兒像，之後研究一下倆者的關係。
2. 書中反覆提到的ENTIRY與VALUEOBJECT的區別筆者一直沒有太明白，之後需要研究一下這塊兒。