1、有效建模的要素

• 模型和實現的綁定
• 獲得了一種基于模型的語言
• 開發一個蘊含豐富知識的模型
• 提煉模型

2、知識消化

         在傳統的瀑布方法中，業余專家與分析員進行討論，分析員消化理解這些知識后，對其進行抽象并將結果傳遞給程序員，再由程序員編寫軟件代碼。由于這種方法完全沒有反饋，因此總是失敗。分析員全權負責創建模型，但他們創建的模型只是基于業務專家的意見。他們既沒有向程序員學習的機會，也得不到早起軟件版本的經驗。知識只是朝一個方向流動，而且不會形成積累

         有些項目使用了迭代過程，但由于沒有對知識進行抽象而無法建立起知識體系。開發人員聽專家們描述某項所需的特性，然后開始構建它。他們將結果展示給專家，并詢問接下來做什么，如果程序員愿意進行重構，則能保持軟件足夠整潔，以便繼續擴展它；但如果程序員對領域不感興趣，則他們只會學習程序應該執行的功能，而不會學習它背后的原理。雖然這樣也能開發出有用的軟件，但項目永遠也不會從原有特性中自然地擴展出強大的新特性。

          好的程序員會自然而然地抽象并開發出一個可以完成更多工作的模型。但如果在建模時只是技術人員在唱獨角戲，而沒有領域專家的協作，那么得到的概念將是很幼稚的。使用這些膚淺知識開發出來的軟件只會做基本工作，而不會充分反映出領域專家的思考方式。

3、持續學習

         高效率的團隊需要有意識地積累知識，并持續學習。對開發人員來說，這意味著既要完善技術知識，也要培養一般的領域建模技巧。但這也包括認真學習他們正在從事的特定領域的知識。

         善于自學的團隊是團隊的中堅力量，那些涉及最關鍵領域的開發任務要靠他們來攻克。這個核心團隊頭腦中積累的知識使他們成為更高效的知識消化者。

4、知識豐富的知識

          當我們的建模不再局限于尋找實體和值對象時我們次啊能充分吸取知識，因為業務規則之間可能會存在不一致。領域專家在反復研究所有規則、解決規則之間的矛盾以及修改規則使其符合常識等一系列工作中，往往不會意識到他們的思考過程有多么復雜。軟件是無法完成這一工作的，正是通過與軟件專家緊密協作來消化知識的過程才使得規則得以澄清和充實，并消除規則之間的矛盾以及刪除一些無用規則。

5、深層模型

         有用的模型很少停留在表面層次上。隨著對領域和應用程序需求的理解逐步加深，我們往往會丟掉那些最初看起來很重要的表面元素，或者切換它們的角度。這時，一些在開始時不可能發現的巧妙抽象就會漸漸浮出水面，而它們恰恰切中問題的要害。