建模原則：（）
1。設計一個模型時應使該模型最頻繁修改的部分所影響的類型數量達到最少。
2。只要爲一個擁有超類型的類型定義了特徵，就應該考慮將這些特徵放在該超類型上是否有意義。
3。將模型清晰地分解成操作級和知識級
4。當多個屬性與可能會在幾個類型中使用的行爲相關時，就把這些屬性組合成新的基礎類型。
5。操作級中的對象會經常發生變化，它的配置由很少發生變化的知識級來約束。
6。如果某個類型擁有多種的關聯，可以爲這些關聯對象定義一個新的類型，並建立一個知識類型來區分它們。
7。要記錄一個值的變更歷史，可以爲這個值設立一個賬目。
8。在使用賬目進要遵守守恆原理：需要清算的物品不能憑空生成和消失，它僅僅是從一個地方轉移到另一個地方，這使得發現和防止不守恆變得容易。
9。當可以提供不止一個的等價特徵集合時，就挑選領域專家最滿意的一種方法。如果領域專家感到兩種方法都有價值，那麼就都顯示，並且把其中一個標記爲派生的。
10。把一個特徵標記爲派生是對接口的一種約束，但不會影響基礎的數據結構。
11。如果一組對象可以用不同的標準來組織，就應當使用合同夾。
12。當把一個過程看作類型的一個特徵時，應該把這個過程提供一個抽象的接口，使得實現能輕鬆地通過子類化而改變，一個通過硬編碼得到的實現是一個子類，不同的參數驅動方法是其他的子類。
13。當多重屬性和一個可能在幾個類型中使用的行爲進行交互時，屬性應該被結合成一個新的基本類型。
14。如果超類的適用領域狹窄而子類的適用領域廣泛，就不應該使用泛化。
15。如果兩個相似類型的差異經常被忽略，那麼一個抽象超類型就可以被使用，如果它們之間的差異通常是很重要的，那麼一個抽象的超類就不應該被使用。
16。如果一個抽象類型從不需要客戶花費更多的努力來使用，那麼它就應該被提供。
17。場景應該在價格或匯率的組合需要被看作一個整體的時候使用。
18。當信息可以從一個信息源檢索或者可以從其它可用的數據計算時，應當提供一個抽象的接口而源和計算各爲一個子類。
19。日期計算經常受到需要跳過的假日的影響，不同國家之間的假日通常是不同的，甚至不同商業機構也有自己的假日。
20。派生標誌應該被用來定義從模型中其它結構中派生的術語。
21。當面對可選擇的方法時，首先要選擇最簡單的，並且當需要時改爲更復雜的方法。
22。當可選擇的模型之間的選擇餘地很少時，聽領域專家的直覺。
23。只有當所有的超類型的特徵適合超類型並且從概念上講每一個子類型的實例是一個超類型的實例有意義時才應該使用子類型化。
24。當客戶眼中的一個交易在交易人眼中是多個交易時，都可以使用產品/合同這種劃分。
產品和合同之間關鍵區別是產品描述客戶的目的而合同涉及對方團體和主要團體之間的交易實際上得到了什麼。
25。不要複製有相同內涵的基礎關聯，遵循這個原則導致責任分明的類型。
26。在責任分配中保持一致。提防一種類型有時對某事負責而有時又將這個責任委託給別的類型（這種行爲可以膽正確的，但它總是值得懷疑）
27。關於狀態圖的泛化結果不能被很好地理解，確保關於超類型的所有事件可以由子類型來操作是很重要的。任何可被子類型化的狀態圖必須允許未知的事件。
28。單向關聯和雙向關聯之間的決定是減少相關開發者的工作（通過減少類型間的耦合）和爲類型的使用者提供方法之間的折衷。
29。如果一個包只需要對另一個包的一部分可見性，那麼考慮將後面的包分成兩個相互可見的包。
30。如果你遇到一個難以建模的重複情況，可以定義一個符號。然而，我們只有當造成的簡化性超過了記憶額外符號的困難時纔會定義一個符號。