Repository設計思路
像模塊化系統、模塊化代碼一樣，模塊化數據庫中的表。使得每個模塊之間有清晰的界限。
Repository代碼設計
- 可以將Repository理解為一個集合（這里的集合更偏重於是Collection，而不是Set），它包括了對存儲對象基本的增刪改查（CURD）功能。同時，Repository還包括滿足領域層的一些特定的功能（注：在Repository中包括這些功能是合理的，首先這些功能是底層設施應該提供給上層的領域層的，其次在這里實現可以更好的利用底層設施的特點來進行性能優化）（注：在一般領域驅動設計的項目中分層都是上層依賴下層，這里的設計卻更偏向於下層基礎設施層依賴於上層領域層。應該可以發現，這里Respository的需要包含的功能都是由上層領域層需要什么決定的，而不是由下層基礎設計層能提供什么決定的。筆記認為這樣的設計其實是更合理的，《Clean Architecture》一書的作者也與筆者持有相同的觀點。這個問題的講述可以單獨寫一篇博客，再這篇文章里不再細究）。
- 不是每張表都需要有一個Repository(在Mybatis中aka：Mapper）與之對應，更准確的說：應該將數據庫中的全部表表聚積到幾個根對象上（聚積方法后面講），這個根對象應該有Repository，而聚積在這個根上的對象不應該有Repository。對這些非根對象的訪問，應該通過於根對象的對象關系來實現。
- （注：和第一條緊密相關，我暫時沒有想清楚他倆之間的聯系）正確的組合搜索於關聯。搜索，即通過給Repository傳遞查詢參數來獲取對象；關聯，即通過要訪問對象與通過搜索得到的對象的關聯來獲取對象。
- Repository應該是一個接口，將其實現與領域層的需求解耦。同時，方便測試時進行插樁和mock。
- 雖然通過接口解耦了Repository與領域層，但是即便是領域層的開發人員，也應該清楚Repository的實現。避免出現性能問題。
- Repository不插手事務，將事務管理交由上層領域層和應用層管理。
- Repository應該讓客戶感覺到那些對象就好像駐留再內存中一樣。
- 根是Aggregate中包含的一個特定的Entity。在一個Aggregate中，根是唯一允許外部對象保持對它的引用的元素，而邊間內部的對象之間則可以互相引用。
數據庫模式（database schema）設計
筆者認為的書中不嚴謹的地方
- P104，書中寫道：
當然，如果在Java中查詢所返回的對象是集合時，客戶不管怎樣都要執行這樣的轉換。
Java1.4添加了泛型之后，返回集合時，不再需要用戶進行強制類型轉換。作者寫書時，Java1.4應該還沒有發布，所以這樣描述並沒有錯誤。但是，這可能給后來的讀者造成一些困惑。
TODO
- P102頁中提到的一種靈活的、聲明式的表示搜索標准的方法於Mybatis中的Example的概念有點兒像，之后研究一下倆者的關系。
- 書中反復提到的ENTIRY與VALUEOBJECT的區別筆者一直沒有太明白，之后需要研究一下這塊兒。