《領域驅動設計》第一部分：讓領域模型發揮做用 第三章：綁定模型和實現 閱讀筆記

內容概述

綁定模型和實現

這章開始，做者舉了倆個案例。第一個案例中，技術分析人員和業務專家共同討論，得出了一個詳盡複雜的領域模型。可是開發人員沒法將這種複雜的模型轉化成可存儲、可檢索的且具備事務完整性的單元。因而開發人員專門針對程序開發的設計了新的模型。第二個案例中，系統以前的C++應用程序，只是把功能堆積在一塊兒。設計就是在已有代碼的基礎上一個一個地堆積新功能，沒有任何明顯的泛化或者抽象。
雖然第一個案例中進行了領域建模，可是因爲實現模型和領域模型分離。最終產生的結果與第二個沒有進行領域建模的項目相同，都是系統實現最終實現了系統功能，可是代碼難以理解和維護。於此，做者提出領域設計的一個要求：

領域驅動設計要求模型不只能知道早期的分析工做，還應該成爲設計的基礎。

3.1模型驅動設計

沒有領域模型的系統，沒法利用知識消化和溝通的好處。若是涉及複雜的領域就會使項目舉步維艱。
使用了領域模型，可是沒有把代碼實現和模型緊密聯繫起來的系統。致使在建模上花費的精力只能在項目初期用來作一些探索工做，而沒法保證程序設計的正確性。
有的設計方法提倡使用徹底脫離程序設計的分析模型，可是做者認爲若是整個程序設計或者核心部分沒有與領域模型相對應，那麼這個模型就是沒有價值的。
模型驅動設計不將分析模型和程序設計分離開，而是尋去一種可以知足這倆方面需求的單一模型。

3.2建模範式和工具支持

我沒有理解做者在這一節要表達地內容。我也不喜歡所謂的面對對象程序設計。

3.3揭示主旨：爲何模型對用戶相當重要

講述一個關於IE瀏覽器收藏夾功能實現的案例：IE瀏覽器將用戶收藏的每一個網站存儲爲一個文件，網站名爲文件名。這種實現模型與用戶期待的模型不一樣致使的用戶體驗差。由此得出，程序設計應該基於一個可以反映出用戶和領域專家所關心地基本問題的模型。

3.4建模人員參與程序開發

建模人員都必須花時間瞭解代碼。每個開發人員都必須學會用代碼來表達模型，而且不一樣程度地參與模型討論，與領域專家保持聯繫。

總結

模型的做用：1. 支持有效的實現；2. 抽象出關鍵的領域知識；
系統中多個模型之間，應該儘量一致甚至可使用同一個模型，以便充分發揮模型的做用。達成這一目標的實現方法：

• 開發人員應該根據模型寫代碼

• 模型設計人員應該參與編碼工做，親身感覺程序實現的約束

  個人觀點和感覺

統一模型，這點筆者是有所感觸的。在某公司實習期間，和PM的交流中會出現：

產品經理：「在已有的基礎之上增長X這個功能因該很簡單，能很快完成吧？」
開發人員: 「代碼不是這麼實現的，因此新增這個功能的工做量很大。」
產品經理：「那大家是怎麼實現的？」
開發人員：「balabala~。」

而後，這個需求根據其重要和緊急程度性，要麼通過較長的開發時間開發完成，要麼就被推遲或者砍掉。
若是多方參與到領域模型的設計，並在各自的工做中使用同一個模型。由此，增長雙方的交流，提升溝通和工做效率。

就文章寫做，我認爲第一節和這章的開始處內容重複。第2、三小節內容內容幫助很小。