2011-05-19 114 views
1

我可以使用一些幫助理解我的域模型,並確保我正確地接近設計。定義邊界和聚合根之間的通信

我有一個稱爲部門的聚合根。 Department對象具有多個子值類型,可幫助定義「部門」的業務概念。在我的用戶界面中,用戶可以列出,創建,編輯和刪除部門對象。

我有另一個稱爲項目的聚合根。一個項目有幾個孩子價值類型,但也與部門有關係,因爲每個項目都是由一個部門「擁有」的。項目可以創建,編輯,刪除等,這樣做對部門沒有影響,而刪除部門也會刪除它擁有的任何項目。

我的用戶界面將根據當前用戶有權訪問的部門顯示項目列表。他們可能可以訪問多個部門。當同時顯示爲列表項目和詳細信息時,我需要在項目中顯示部門徽標。

我的第一個想法是該項目是一個具有簡單DepartmentID屬性的聚合根,可用於'查找'部門。但現在我開始認爲我真的只有一個聚合根:部門。

您認爲如何?

UPDATE

我不知道這是否是關鍵討論或改變什麼,但下面的思想讀第一對夫婦的答案後,發生在我身上。

處似乎有兩個背景:

  1. 作爲該 支持修改一個獨立的實體。
  2. 作爲 案件中包含只讀數據和 項目的子項目沒有任何行爲。

這讓我覺得我應該在我的模型中有兩個'對象',案例#1的聚合根和案例#2的值類型。我在正確的軌道上嗎?

回答

1

由於項目不能存在沒有部門它可能不是一個聚合根。從你的描述來看,你聽起來像只有一個AR--部門,你用它來管理裏面的項目。

如果你的行爲大多是CRUD,我不建議爲它建立一個完整的域模型,因爲可能有更簡單的方法。

UPDATE 正如你所提到的,你可能在這裏有兩個有界的上下文。一個部門是AR和項目是AR的實體。在這種情況下,您將對您的部門執行操作。在公元第二年,您的項目可能是AR,部門可能是實體或VO。這將允許您直接處理項目。

我還建議您與您的領域專家一起討論這些問題,看看這些概念是否適合您的UL,或者尋找一些可以澄清您的模型的缺失概念。我特別想找一個可能將項目與部門聯繫起來的概念。

+0

只有部門的接口/ API是CRUD。有很多與項目相關的操作和行爲,這就是爲什麼我最初將其視爲一個聚合。 – SonOfPirate 2011-05-20 11:19:19

+0

即使一個項目如果沒有所有權而不能「存在」,這難道不是一個有效的規則嗎?我的意思是,如果Project不是一個聚合根,那麼當我的許多用例開始瀏覽項目列表,選擇一個項目並執行任務時,我必須實例化部門以導航到項目針對該項目,例如編輯它的屬性。我真的需要通過Department來做到這一點嗎?在這種情況下,Department只是一個價值型裝飾項目嗎?這是我混亂的根源。 – SonOfPirate 2011-05-20 11:21:46

+0

如果您將它們建模爲單獨的AR,然後刪除部門,如果您還想刪除項目,則必須使用跨AR的工作單元,這是不推薦的,在某些情況下甚至可能不可能(分區,事件採購)。我會更新答案以提供有關更新部分的信息。 – 2011-05-20 13:20:10

1

我認爲完全有理由讓Project和Department都是聚合根,因爲它們都是獨立管理的。

也就是說,每個項目和每個部門都有某種唯一的標識符,雖然可以將項目添加到部門,但項目本身可能足夠複雜(擁有自己的生命週期,自己的子對象等)以保證聚合根狀態。

您只需在每個項目中保留對該部門的參考。要回答

+0

您的意思是「在每個項目中引用該部門」的字面意思,因爲當我返回一個Project對象時,它包含對關聯的Department對象(及其所有子對象)的引用?如果Project需要時暴露一個DepartmentID屬性並通過其他方式查找Department對象,會更好嗎? – SonOfPirate 2011-05-20 12:31:07

+0

那麼,在你的域名中你可以保留一個實際的引用,或者只是一個Guid(或其他唯一標識)屬性。 這取決於你是否總是需要訪問每個項目,只要你在你的部門工作,我認爲這不太可能。 只要您正確地管理關係,您對域的建模方式真的取決於您。到目前爲止,我更喜歡使用ID。假設您的Project聚合根擁有一個DepartmentId屬性。那麼萬一您的業務邏輯需要它,您只需通過調用其GetById方法從DepartmentRepository中檢索正確的部門。 – 2011-05-20 12:48:02

+0

很多人喜歡只參考Id。我使用Nhibernate。 Nhibernate具有延遲加載,所以實際上我只有id,直到我嘗試訪問另一個聚合,然後NH去獲取它。這個摘要檢索另一個ag。關於你的陳述「對相關部門對象(及其所有子女)的引用」我認爲如果你要保持對實際對象的引用,那麼你必須使用某種形式的延遲加載。否則,在非常短的時間內,您將檢索一個對象,並在內存中結束整個系統對象圖。 – Raif 2012-06-30 17:15:01

0

幾個簡單的問題:

1)可以在部門域對象居住通過自身沒有項目域對象。 - 如果是的話,那麼該部門是一個整體。

2)是該項目的域對象可通過其自身的生活 - 如果是,則該項目還聚集

3)是項目與一個部門的關係 - 那麼它應該是項目集合的一部分作爲財產部門公開

4)部門是否與一個或多個項目對象有關係 - 項目彙總應該是部門彙總對象的一部分。

因此,使用Department集合對象,您可能需要訪問Project對象的列表,並且一旦擁有Project對象,您可能需要訪問Department對象。這是一個過時的罰款循環參考。

這是員工有一個經理和經理有一個員工名單的典型示例

+0

是的所有4個問題。你將如何處理關係?項目的部門財產是否參考實際的部門對象或代表該部門的輕量值對象? – SonOfPirate 2011-05-21 01:20:40