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