大明湖畔的領域模型
不管在做系統分析,還是系統設計時,我們大概率都會提到領域模型這個詞,奇妙的是雖然大家都在談論領域模型,但每個人心中都有一份對領域模型的認知。
套用 DDD,我們需要統一語言,首先需要對 “領域模型” 有一個統一認知。達成共識。
你可以暫時掛起大腦進程,想想:“領域模型是什麼?怎麼描述?”
世事萬物都在變化中發展,就如同 “手機”,十年前和現在,人們對它的認知也是不一樣的。所以我們一起回顧一下最原始的“領域模型” 是什麼,你是否記起大明湖畔的領域模型。
“領域模型” 最早流行於 OOA 中,簡單回顧一下 OOA/D
OOA/D
分析:強調的是對問題和需求的調查研究,而不是解決方案。例如,如果需要一個新的在線交易系統,那麼,應該如何使用它?它應該具有哪些功能?
設計:強調的是滿足需求的概念上的解決方案,而不是實現。例如,對數據庫方案和軟件對象的描述。設計思想通常排斥底層或 “顯而易見” 的細節。最終設計可以實現,而實現則表達了真實和完整的設計。
分析和設計可以概括爲:做正確的事和正確地做事
OOA:強調在問題領域內發現和描述對象(或概念)。例如,在航班信息系統裏包含飛機、航班和飛行員等概念。
OOD:強調的是定義軟件對象以及它們如何協作以實現需求。例如,軟件對象 Plane 可以有 tailNumber(飛機唯一標識) 和 getFightHistory 方法 (飛行過的航班)
領域模型
領域模型是 OOA 中最重要的和經典的模型。
定義
領域模型是對領域內的概念類或現實世界中對象的可視化表。也稱爲概念模型、領域對象模型和分析對象模型。
不是描述軟件類、軟件架構領域層或有職責軟件對象的組圖。
Why
爲什麼需要領域模型?去掉修飾語,爲什麼需要模型,這在 DDD 系列文章中已經解釋:模型是對業務複雜度的簡化和提煉。幫助我們更好地理解業務。
同理領域模型能夠使我們理解關鍵概念和業務知識。
我們在設計和實現時,軟件類名稱也大多源於領域模型的名稱,以使對象具有源於領域的信息和職責。
這樣可以降低我們思維與 OO 建模之間的表示差異
How
如何創建領域模型?
- 尋找概念類 2. 將其繪製爲 UML 類圖中的類 3. 添加關聯和屬性
尋找概念類
根據領域模型定義,需要先找到概念類。
概念類是思想、事物或對象。可以從其符號、內涵和外延考慮。
符號:表示概念類的詞語或圖形
內涵:概念類的定義
外延:概念類所適用的一組示例
考慮購買交易事件的概念類。
可以使用符號 Sale 對其命名。
Sale 的內涵陳述爲 “表示購買交易的事件,並且具有日期和時間”
Sale 的外延是所有銷售的例子,或者說是世界上所有銷售實例的集合
描述類圖
領域模型描述的信息可以採用純文本方式表示。
但是在可視化語言中更容易理解這些術語,特別是它們之間的關係,因爲我們的思維更擅長理解形象的元素和線條連接。
在應用 UML 時,領域模型被描述爲一組沒有定義操作的類圖。
關聯
關聯是類之間的關係,表示有意義和值得關注的連接。
關聯能夠滿足當前所開發場景的信息需求,並且有助於理解領域。
關聯被表示爲類之間的連線,並冠以首字母大寫的關聯名稱。
關聯末端可以包含多重性表達式,用於指明類的實例之間的數量關係。
關聯本質上是雙向的,方向箭頭只是爲了方便閱讀,默認是從左往右。
總結
沒有所謂唯一正確的領域模型。所有模型都是對我們試圖要理解的領域的近似。
領域模型主要是特定羣體中用於理解和溝通的工具。
有效的領域模型捕獲了當前需求語境下本質抽象和理解 領域所需要的信息,並且可以幫助理解領域的概念、術語和關係。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/W2BVamXGubdz_x5VA1x-Zg