我想基於現有的基於C#WinForm的系統爲我的域建模,這是爲了提高我對DDD的學習,所以我將一個假設的概念模型放在一起以簡化問題。系統本身並沒有一個典型的業務領域,其中有許多邏輯混合到實體框架對象中,這些對象在系統的所有方面都被使用。我覺得這是一個大泥球(BBOM)。DDD概念模型到集合根域模型
我已經在工作中解決了一些DDD概念,但我想提高我對整體的理解。我閱讀了Evans的藍皮書「領域驅動設計:解決軟件中的複雜性」以及Scott Millets的「域驅動設計的模式,原則和實踐」。以及觀看關於這個主題的無數視頻,以及沃恩弗農的articles。我覺得這些年來已經完成了更多的數據驅動開發,因此需要花費一個時間才能沉入其中。
因此,假設系統是一個嚴格的質量控制系統,用於構建鬆散地跟隨系統的產品。
這裏是概念模型:
現在我看到3個環節進行 - 不一定是有界的背景,但我在努力查明這些約束背景所在。
有業務流程的3個部分:
- 定義產品
爲此,「用戶」將輸入的各種產品信息,包括名稱。作爲其中的一部分,他們定義了產品應該是什麼樣的厚度以及它由什麼材料製成。他們還將定義Builder需要使用什麼過程來構建產品。他們還定義是否需要視覺檢查和質量檢查。
- 建立產品
- 檢驗
- 未組裝
- 組裝
- 部分檢查(在兩次檢查中的一個已經完成)
- 通過驗收(所有檢驗完成)
- 檢驗不合格(任何檢查失敗)
- 該系統被設計爲在那裏檢查可以在同一時間被輸入多用戶
- 可能的是,數據在其上可被校正的產品可能違反對輸入生成輸入錯誤和檢查數據
- 輸入的數據然後用於各種報告。
- 凡我限界上下文的謊言。
如何建模我的聚合根 - 哪些數據應該是根,以及應包含哪些實體/值對象。
我是否只在有界的上下文中包含我需要的域對象的數據 - 也就是說不要充分保護域對象。
如何實現某些功能來通過過程的不同部分來計算狀態。
- 如何處理錯誤輸入數據以保持域數據正確的可能性。
作爲處理的 「助洗劑」,將組裝產品的一部分。但是,這僅限於建築商的資格。生成器可以針對基於厚度範圍和材質的工藝進行限定,所以如果生成器符合「工藝厚度範圍」和「材質」之間的「產品厚度」,則業務規則只允許選擇生成器。
一旦產品已經建成,它可以被檢查。作爲其中的一部分,根據是否需要視覺或質量檢驗類型,最新的合格「檢驗員」將能夠檢查產品。他們會通過或不通過檢查。
作爲通過這些流程的流程的一部分,產品的狀態將被更新。這將是:
以下是關於需要一些想法的域外系統的一些信息:
所以我需要一些想法,以:
我對任何存儲庫實現都不感興趣,只是純粹的域的概念,雖然問題我們應該堅持每個有界的上下文會幫助我。
我有我的顧慮是有多個用戶輸入數據,保證數據圍繞產品狀態
這些是不同的問題。我想你應該爲他們提出單獨的問題。 – guillaume31
有界上下文/總體設計通常是分析現實生活約束和使用領域專家建模的結果。由於您沒有這些強大的業務和技術限制來指導您,所以製作好的域名很難使用。由於所有這些問題都沒有真實世界的事實來決定,所以發現自己陷入分析癱瘓的風險很高。 – guillaume31
同意。但爲了在這裏保持一個簡單的例子,我把這個概念與我認爲足夠詳細的概念放在一起,希望能夠從某種意義上了解從哪裏開始。我限制誰可以根據一些業務規則來執行構建。這些數據被捕獲並輸入。域模型可以防止在構建器不合格的情況下進入構建。也許我的確投入了太多,但如果我可以重新解釋這個問題的話,我會 - 在圖上將一些代碼組合在一起。我想確定有界的情況會在之後出現。有什麼想法嗎? – Andez