【讀書心得】Domain-Driven Design領域驅動設計

 名詞解釋:

        模型(model)：是一種簡化。它是對現實的解釋:把與解決問題密切相關的方面抽象出來，而忽略無關的細節。領域(domain)所需的知識廣度可能令人望而生畏，龐大而複雜的資訊也可能超乎想象。模型正是解決此類資訊超載問題的工具。模型這種【知識形式】對知識進行了【選擇性的簡化】和【有意識的結構化】。

圖片來源：https://i1.kknews.cc/SIG=1sreuag/ctp-vzntr/86pp7r00r41o43pso28qr33847p0os34.jpg

重點摘要:

    partI：

        一、領域驅動的設計中，三個基本用途決定了模型的選擇；1.模型和設計的核心互相影響 2.模型是團隊所有成員使用的通用語言的中樞. 3.模型是濃縮的知識。

        二、軟體的核心：軟體的核心是它為解決領域相關的問題的能力。所有其他特性，不管有多麼重要，都要服務於這個基本目的。

   chapter 1:消化知識

      一、模型透過不斷的與domain專家討論domain-knowhow後，產生不斷精化後模型的類別圖。

 chapter 2:交流與語言的使用

    一、討論以UML的類別圖及物件交互圖為主。但UML圖無法完整表達【模型所表示的概念】、【物件應該做那些事情】，這部份可以文字補充說明。圖是一種溝通的手段，精簡小圖效果最好。涵蓋整個物件模型的【綜合性大圖】反而失去了溝通或解釋的能力。所以我們應該使用【簡單】且【只包含物件模型重要概念】的圖。務必要記住模型不是圖 ，圖的目的是幫助表達和解釋模型。

二、書面設計文件（文件通用原則）

• 文件應作為程式與口頭交流的補充
• 文件不應再重複表示【程式碼已經明確表達出的內容】:應著重在說明意義,讓我們能夠理解大型結構，並將注意力擺在核心元素上。
• 文件應當保持最新：文件最大的價值在於【解釋模型的概念】，幫助我們在程式碼的細節找到方向。
• 【解釋性模型】與【類別圖】同時使用更容易理解。

圖片：航運路線的解釋性模型

Chapter 3 綁定模型實作

    
    一、領域驅動設計不只要求模型【協助初期的分析工作】,也要求模型【成為設計的基礎】。

    二、模式：Ｍodel-Driven desing

    三、模式：Hands-ON Modeler