一個團隊，一種語言！

1. 語言，術語的統一很重要。如果語言支離破碎，專案必將遭遇嚴重問題。 討論與寫程式碼中術語不一致，甚至同一個人說的跟寫時不一致，導致對領域有一定的理解認識，也轉眼忘記，無法記錄到程式碼與文件中。
2. 專案需要一種公共語言，領域模型可以成為這種語言的核心。公共語言是整個團隊工作中的通用語言（Ubiquitous Language）。
3. Ubiquitous Language的詞彙表包括類名稱和主要操作。
4. 模型之間的關係成為所有語言都具有的組合規則。詞和短語的意義反映了模型的語義。術語=>規則、大比例結構、ContextMap
5. 知識消化 –> 模型完善 –> 術語意義改變或新術語增加
6. 將模型作為語言的重心，確保團隊在所有交流活動中堅持使用這種語言。畫圖、寫東西、講話… 需要解決術語混淆的問題及有歧義的不一致的地方。Ubiquitous Language以動態形式傳遞知識。
7. 精華模型的最佳方式之一就是通過對話來研究，找出可能的模型變化，並說出對他的多種構想。這樣不完善的地方很容易被聽出來。
8. 討論系統時需要結合模型。使用模型的元素以及模型中各元素之間的互動大聲描述場景，並且按照模型允許的方式將各種概念結合到一起。找到更簡單的表達方式來講出你要講的話，然後將這些新的思想應用到圖和程式碼中。
9. UML有時過於細緻，有時很多遺漏。
10. 圖是一種溝通和解釋手段。（簡潔的小圖可以很好的實現這目標）
11. 圖和文件能夠引導人們將注意力放在核心要點上。通常的做法是以圖為主，輔以文字註釋。而我更喜歡以文字為主，新增精心挑選的簡化圖作為註釋。
12. 務必要記住模型不是圖。圖的目的是幫助表達和解釋模型。（程式碼可以充當設計細節的儲存庫，清晰的程式碼與UML具有同樣的表達能力。）
13. 文件只是作為程式碼和口頭的交流的補充。但程式碼作為一種設計文件，自身也存在侷限性。他能把讀程式碼的人淹沒在細節中。
14. 文件不應再重複表示程式碼已經明確表達出的內容。應著重說明含義，以便使人們能夠深入理解大比例結構，並將注意力集中在核心元素上。
15. Ubiquitous Language可使文件更簡潔和明確。
    當領域模型反映了與業務最相關的知識時，應用程式的需求成為該模型內部場景而Ubiquitous Language可用於描述這樣一個直接與Model-Driven Design有關的場景。結果就是規格說明等文件的編寫更加簡單，t因為他們不必傳達模型背後隱含的業務知識。
16. 通過將文件減至最少，並且主要用它來補充程式碼和口頭交流，就可以避免文件與專案脫節。根據Ubiquitous Language及其演變來選擇那些需要保持最新並與專案活動緊密互動的文件。
17. XP完全依賴可執行程式碼和程式碼測試。但方法名稱可能會有歧義，會產生誤導或者因為已經過時而無法表示方法的本質含義。消除歧義是宣告式設計。要使程式碼所傳達的訊息與他的行為和意圖保持一致，要有嚴格的設計規程和特定的思考方式。
18. 解釋性模型不等於物件模型（技術模型）。
    技術模型必須經過嚴格的精簡，以便用最小的模型來實現其功能。
    解釋性模型可引入其他檢視、工具等，只是為傳遞一般領域知識的教學工具。