大明湖畔的領域模型

不管在做系統分析,還是系統設計時,我們大概率都會提到領域模型這個詞,奇妙的是雖然大家都在談論領域模型,但每個人心中都有一份對領域模型的認知。

套用 DDD,我們需要統一語言,首先需要對 “領域模型” 有一個統一認知。達成共識。

你可以暫時掛起大腦進程,想想:“領域模型是什麼?怎麼描述?”

世事萬物都在變化中發展,就如同 “手機”,十年前和現在,人們對它的認知也是不一樣的。所以我們一起回顧一下最原始的“領域模型” 是什麼,你是否記起大明湖畔的領域模型。

“領域模型” 最早流行於 OOA 中,簡單回顧一下 OOA/D

OOA/D

分析:強調的是對問題和需求的調查研究,而不是解決方案。例如,如果需要一個新的在線交易系統,那麼,應該如何使用它?它應該具有哪些功能?

設計:強調的是滿足需求的概念上的解決方案,而不是實現。例如,對數據庫方案和軟件對象的描述。設計思想通常排斥底層或 “顯而易見” 的細節。最終設計可以實現,而實現則表達了真實和完整的設計。

分析和設計可以概括爲:做正確的事和正確地做事

OOA:強調在問題領域內發現和描述對象(或概念)。例如,在航班信息系統裏包含飛機、航班和飛行員等概念。

OOD:強調的是定義軟件對象以及它們如何協作以實現需求。例如,軟件對象 Plane 可以有 tailNumber(飛機唯一標識) 和 getFightHistory 方法 (飛行過的航班)

領域模型

領域模型是 OOA 中最重要的和經典的模型。

定義

領域模型是對領域內的概念類或現實世界中對象的可視化表。也稱爲概念模型、領域對象模型和分析對象模型。

不是描述軟件類、軟件架構領域層或有職責軟件對象的組圖。

Why

爲什麼需要領域模型?去掉修飾語,爲什麼需要模型,這在 DDD 系列文章中已經解釋:模型是對業務複雜度的簡化和提煉。幫助我們更好地理解業務。

同理領域模型能夠使我們理解關鍵概念和業務知識。

我們在設計和實現時,軟件類名稱也大多源於領域模型的名稱,以使對象具有源於領域的信息和職責。

這樣可以降低我們思維與 OO 建模之間的表示差異

How

如何創建領域模型?

  1. 尋找概念類 2. 將其繪製爲 UML 類圖中的類 3. 添加關聯和屬性

尋找概念類

根據領域模型定義,需要先找到概念類。

概念類是思想、事物或對象。可以從其符號、內涵和外延考慮。

符號:表示概念類的詞語或圖形

內涵:概念類的定義

外延:概念類所適用的一組示例

考慮購買交易事件的概念類。

可以使用符號 Sale 對其命名。

Sale 的內涵陳述爲 “表示購買交易的事件,並且具有日期和時間”

Sale 的外延是所有銷售的例子,或者說是世界上所有銷售實例的集合

描述類圖

領域模型描述的信息可以採用純文本方式表示。

但是在可視化語言中更容易理解這些術語,特別是它們之間的關係,因爲我們的思維更擅長理解形象的元素和線條連接。

在應用 UML 時,領域模型被描述爲一組沒有定義操作的類圖。

關聯

關聯是類之間的關係,表示有意義和值得關注的連接。

關聯能夠滿足當前所開發場景的信息需求,並且有助於理解領域。

關聯被表示爲類之間的連線,並冠以首字母大寫的關聯名稱。

關聯末端可以包含多重性表達式,用於指明類的實例之間的數量關係。

關聯本質上是雙向的,方向箭頭只是爲了方便閱讀,默認是從左往右。

總結

沒有所謂唯一正確的領域模型。所有模型都是對我們試圖要理解的領域的近似。

領域模型主要是特定羣體中用於理解和溝通的工具。

有效的領域模型捕獲了當前需求語境下本質抽象和理解 領域所需要的信息,並且可以幫助理解領域的概念、術語和關係。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/W2BVamXGubdz_x5VA1x-Zg