DDD原著 -- 第三章 綁定模型和實現

1. 領域驅動設計要求模型不僅能夠指導早期的分析工作，還應該成爲設計的基礎。
2. 嚴格按照基礎模型來編寫代碼，能夠使代碼更好地表達設計含義，並且是模型更符合設計。
3. 缺乏設計基礎概念的軟件充其量也只是一種機械化的產品，只實現有用的功能卻無法解釋操作的原因。
4. 很多設計方法都提倡使用完全脫離於程序設計的分析模型，且通常這二者是由不同的人員開發的。但DDD不提倡，因爲這樣會有很多問題。
5. 如果整個程序設計或者其核心部分沒有與領域模型相對應，那麼這個模型就是沒有價值的，軟件的正確性也值得懷疑。模型和設計功能之間太過複雜的對應關係也是難於理解的，在實際項目中改變設計時也無法維護這種關係。分析和設計工作全無關聯，導致在這另個過程中所獲得的知識無法彼此共享。
6. 分析工作一定要抓住領域內的基礎概念，並且用易於理解和易於表達的方式描述出來。
7. Model-Driven Design（模型驅動設計）不再將分析模型和程序設計分離開，而是尋找一種能夠滿足這兩方面需求的單一模型。
8. 綁定模型和程序設計是切實可行的。不能因爲技術問題考慮而 削弱分析功能，也不能只反映領域概念卻捨棄了軟件設計原則。模型和設計的綁定需要的是在分析和程序設計階段都能發揮作用的模型。這樣就結合爲一個統一的迭代開發過程。
9. 軟件系統的各個部分的設計應該忠實的反映領域模型，以便體現出這二者之間的明確對應關係。我們應該反覆檢查並修改模型，在軟件中更加自然地實現模型，即使想讓它反映出更深層次的領域概念也應如此。我們需要的模型不但應該滿足這兩種需求，還應該能夠支持健壯的Ubiquitous Language。
10. 從模型中獲取用於程序設計和基本任務分配的術語。程序代碼就是模型的表達。修改代碼可能就是修改模型。完全依賴模型的實現通常需要支持建模範式的軟件開發工具和語言，比如：面向對象的編程。
11. 知識消化人員需要研究模型的各個選項，並將它們細化爲實用的軟件元素。軟件開發於是就成了一個不斷精化模型、設計和代碼的統一的迭代過程。
12. 要保證模型和設計之間的嚴格的一致性，必須要運用由軟件工具支持的建模範式，它可以直接模擬模型中的概念。如：面向對象編程語言，C#、Java、Prolog。。。對象設計的真正突破是用代碼來描述模型中的概念。
13. 在Model-Driven Design中，建模範式是一種邏輯，而模型則是一組邏輯規則以及這些規則所依據的事實。
14. Hands-ON Modeler（建模人員參與程序開發）
    如果編寫代碼的人員認爲自己沒必要對模型負責，或者不知道如何讓模型爲應用程序服務，那麼這個模型就和程序沒有任何關聯。如果開發人員沒有意識到改變代碼就意味着改變模型，那麼他們對程序的重構不但不會增強模型的作用，反而會消弱他的效果。同樣，如果建模人員不參與到程序實現的過程中，那麼對程序實現的約束就沒有切身的感受，即使有也會很快忘記。最終模型將變得不再實用。最後一點，如果項目組的分工阻斷了設計人員與開發人員的協作，使他們無法領悟Model-Driven Design 的奧妙，那麼經驗豐富的設計人員則不能將自己的知識和技術傳遞給開發人員。
15. 任何參與建模的技術人員，不管在項目中的主要職責是什麼，都必須花時間瞭解代碼。任何負責修改代碼的人員則必須學會用代碼來表達模型。每一個開發人員都必須不同程度地參與模型討論並且與領域專家保持聯繫。參與不同工作的人都必須有意識地通過Ubiquitous Language與接觸代碼的人及時交換關於模型的想法。