5.1 關聯
- 指定一個導航方向
避免多對多。對於多對多並未提出解決方案，個人覺得建立關聯表是個方法。好吧這裡犯了數據庫驅動設計的毛病！
- 加入限定符減少多重性
通過限定將一對多變成一對一，如時間上的限定，同一時間一個人只能有一張申請單，則時間限定就讓人和申請單變作一對一。
- 清除不必要關聯
清除非關注的關聯，但如果需要擴展，我覺得有必要保留部份顯而易見的關聯。
5.2 實體
標識必須唯一。
5.3 值對象
個人認為，在設計時，應將公用值對象的實例持久化，如此做法可以提高性能，因為我們所關注的值對象，並不需要知道他是哪一個實例。具體做法可以研究（如全局變量、緩存技術）。當然，複製和共享所需的開銷，並非總是複製更高。
如果我們只關心模型中一個元素的屬性，那麼就把元素劃分為值對象，不要給他任何標識，可以避免實體維護降低複雜度。
可共享的值對象需要有不變性。
自由的複製值對象有事也能提高性能，在某個實體的數據表中直接存儲某個值而非值引用就是這個道理。
5.4 服務
服務部保留自身狀態
領域層服務關注領域，應用層服務可能并不涉及領域名詞
中等粒度，無狀態的服務容易重用。領域層服務有助於分清領域層和應用層的界限。
5.5 模塊
高內聚，ROOT。