我可以使用一些幫助理解我的域模型,並確保我正確地接近設計。定義邊界和聚合根之間的通信
我有一個稱爲部門的聚合根。 Department對象具有多個子值類型,可幫助定義「部門」的業務概念。在我的用戶界面中,用戶可以列出,創建,編輯和刪除部門對象。
我有另一個稱爲項目的聚合根。一個項目有幾個孩子價值類型,但也與部門有關係,因爲每個項目都是由一個部門「擁有」的。項目可以創建,編輯,刪除等,這樣做對部門沒有影響,而刪除部門也會刪除它擁有的任何項目。
我的用戶界面將根據當前用戶有權訪問的部門顯示項目列表。他們可能可以訪問多個部門。當同時顯示爲列表項目和詳細信息時,我需要在項目中顯示部門徽標。
我的第一個想法是該項目是一個具有簡單DepartmentID屬性的聚合根,可用於'查找'部門。但現在我開始認爲我真的只有一個聚合根:部門。
您認爲如何?
UPDATE
我不知道這是否是關鍵討論或改變什麼,但下面的思想讀第一對夫婦的答案後,發生在我身上。
處似乎有兩個背景:
- 作爲該 支持修改一個獨立的實體。
- 作爲 案件中包含只讀數據和 項目的子項目沒有任何行爲。
這讓我覺得我應該在我的模型中有兩個'對象',案例#1的聚合根和案例#2的值類型。我在正確的軌道上嗎?
只有部門的接口/ API是CRUD。有很多與項目相關的操作和行爲,這就是爲什麼我最初將其視爲一個聚合。 – SonOfPirate 2011-05-20 11:19:19
即使一個項目如果沒有所有權而不能「存在」,這難道不是一個有效的規則嗎?我的意思是,如果Project不是一個聚合根,那麼當我的許多用例開始瀏覽項目列表,選擇一個項目並執行任務時,我必須實例化部門以導航到項目針對該項目,例如編輯它的屬性。我真的需要通過Department來做到這一點嗎?在這種情況下,Department只是一個價值型裝飾項目嗎?這是我混亂的根源。 – SonOfPirate 2011-05-20 11:21:46
如果您將它們建模爲單獨的AR,然後刪除部門,如果您還想刪除項目,則必須使用跨AR的工作單元,這是不推薦的,在某些情況下甚至可能不可能(分區,事件採購)。我會更新答案以提供有關更新部分的信息。 – 2011-05-20 13:20:10