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