項目管理系統的域驅動設計方法C＃ASP.NET 3.5

我正在使用C＃3.0和ASP.NET 3.5與SQL Server 2008 R2後端編寫一個簡單的項目管理系統。項目管理系統的域驅動設計方法C＃ASP.NET 3.5

目前它本質上是一個數據驅動的應用程序，具有基本的CRUD功能，少量的業務邏輯和一些驗證。

預計該系統將增長到包含更復雜的業務功能，我有興趣嘗試使用域驅動設計（DDD）的原則對其進行重新編碼。

我意識到這對於目前系統的狀態是如何矯枉過正，並且我預計現在要創造一個貧血的領域。該系統由客戶，客戶，項目，組件和活動組成。

客戶有0,1或許多客戶。客戶擁有0,1或多個項目項目擁有0,1或多個組件和組件具有0,1或多個活動。

我該如何使用DDD進行建模？我是否將客戶，客戶，項目，組件和活動視爲聚合根？或者我是否擁有一個聚合根（客戶），並將客戶，項目，組件和活動作爲實體通過客戶訪問？是否有推薦的方法來建模實體/聚合根之間的多對一關係？我知道這並沒有涉及價值對象（顯然客戶，客戶端等包含幾個屬性）等，但我是一個完整的初學者在這裏，會喜歡一些指針和近乎完整的答案。

對這個問題的開放性問題抱歉，我已經有一個工作系統，但展望未來。

謝謝，豐富。

來源

2012-09-04 Richard Knight

一個好的領域模型由一組相互交互處理業務用例之間的連接對象的。如果你想使用DDD，你首先需要先弄清楚什麼是用例。你能否添加更多關於你的項目支持哪些用例的信息？ – nwang0

感謝您的回答。我想我會去閱讀Domain Driven Design。 –

域驅動設計的核心不是軟件分析，而是業務分析。應用DDD的想法和模式可能會讓您最終得到不會被稱爲客戶，客戶，項目，組件和活動的聚合和實體。

預設一組給定的類/實體並試圖對它們實施DDD構建塊可能無法儘快獲得您的幫助。

對於初學者，我只能推薦（重新）閱讀這本書的領域驅動設計Eric Evans。並且不僅前幾章，後面的部分（第3部分 - 重構深入透視和第IV部分 - 戰略設計）比處理低級別構建塊的更多策略第II部分重要得多。

更新：如果你只想做一個造型的運動，而不耗時分析（這使得DDD如此昂貴並且只適合於複雜的領域），我建議你閱讀Streamlined Object Modelling: Patterns, Rules, and Implementation。

來源

2012-09-04 11:35:18

您能否詳細說明爲什麼您認爲聚合和實體不會被稱爲客戶，客戶等？對我而言，這看起來很可能是領域專家使用的語言的一部分。 –

@DanielHilgarth這將在特定域名和不同團隊之間有所不同。當然沒有對錯。我想說的是，進行適當的業務分析可以發現比「採用名詞，讓他們上課，動詞並使他們成爲方法」的舊方法更合適的概念。 –

感謝您的回答。我想我會去閱讀Domain Driven Design。 –

平時我把所有這個類型的元素作爲骨料的根，你看不到未來的成長或模型的變化，如果你將需要訪問活動，作爲一個獨立的實體，例如，以使活動的報告，按活動類型分組並按月分段，並創建一個子報表以便客戶或客戶分解信息，從這一點開始嘗試從客戶那裏收集報告 - 客戶 - 活動很難並且確定您需要添加一些代碼來處理回覆並做出報告。

你能想到的客戶一個根，但切忌不要對孩子的實體父引用，我認爲這是沒有頭痛的最佳實踐。

來源

2012-09-04 11:45:12 Clot

感謝您的回答。我想我會去閱讀Domain Driven Design。 –

項目管理系統的域驅動設計方法C＃ASP.NET 3.5

回答

相關問題