領域模型（二）

model-driven design（模型驅動設計）利用模型來為應用程式解決問題。

團隊成員通過ubiquitous language（通用語言）交流進行知識消化，以便有效建模，而model-driven design繫結模型與實現，以此為出發點做出的軟體產品才能在完全理解核心領域的基礎上提供豐富的功能。

1、繫結模型與實現。實現要反映模型的變化，實現不能脫離模型，憑空實現；

2、通用語言。團隊溝通同一問題領域要統一語言，以模型為語言核心；

3、開發乙個蘊含豐富知識的模型；

4、提煉模型。要選擇性簡化和有意結構化；

5、頭腦風暴和試驗。不斷地對模型進行可行性測試；

答：開發人員和領域專家等團隊人員之間共同協作，共同收集領域相關資訊，資訊**多種多樣，有可能是書籍資料、電子文件、也有可能是人們的專業知識、經驗等。他們通過消化吸收這些領域知識並將它組織為有用的形式，即模型。知識消化是一種探索，它永無止境。

答：1、領域模型可成為軟體專案通用語言的核心。

2、ubiquitous language的詞彙包括類和主要操作的名稱。語言中的術語，有些用來討論模型中已經明確的規則，還有一些來自施加於模型上的高階組織原則（如context map和大型結構等）。

3、通用語言的更改就是對模型的修改。

4、在敏捷過程中，需求是隨著專案的前進而演變的，故用不斷精化後的ubiquitous language重新組織需求應該是專案演變過程中的一部分。

答：與驅動設計模型（物件模型）相比，解釋性模型具有一定的自由度，不一定是類圖等物件模型，它可以用一種不同的方式來呈現領域，幫助團隊成員更好、更直觀的理解驅動設計模型。

定義：model-driven dsign（模型驅動設計）不再將分析模型與程式設計分離開，而是尋求一種能夠滿足這兩方面需求的單一模型；

表現：不考慮技術問題，程式設計中的每個物件都反映了模型中所描述的概念。從模型中獲取用於程式設計和職責分配的術語，讓程式**成為模型的表達，**的修改可能會是模型的改變；

實現：完全依賴模型的實現通常需要支援建模範式的軟體開發工具和語言，比如物件導向的程式設計；

結果：軟體開發於是就成了乙個不斷精化模型、設計和**的統一的迭代過程；

四個必須

任何參與建模的技術人員，不管在專案中的主要職責是什麼，都必須花時間了解**。

任何負責修改**的人員都必須學會用**來表達模型。

每乙個開發人員都必須不同程度地參與模型討論並與領域專家保持聯絡。

參與不通工作的人都必須有意識的通過ubiquitous language與接觸**的人及時的交換關於模型的想法。