聚合根設計和大小

我知道有這樣的一百萬個問題。對不起。我認爲我是不同的，但似乎並非如此。我是DDD的新手，並試圖抓住。我的部分域名是這樣的。位置1 *場場1 *事件場1 *任務任務-員工聚合根設計和大小

現在看來，當AR的位置。如果我想要完成特定的任務，我必須通過收集任務集中的字段來遍歷任務。

這聽起來相當費力，因爲我處理的任務和事件很多，幾乎從來沒有說每個位置的位置。該位置用於隔離一組字段及其對應的實體。所以在UI中，我可以選擇一個位置並獲得一個字段列表。然後我會選擇一個領域。從那裏我可以編輯它的任務之一。所以我有一個任務集合，我選擇一個，所以我有任務的Id。然後，我需要遍歷到位置並獲得他的ID，以便我可以獲得AR並回溯到任務。或者說，我會保持AR的Id，以便我能夠得到它。那麼我是否也應該保持領域的Id？所以我回到服務器的是AR.Id，Field.Id和Task.Id，我想看看？其次，員工當然不可能是一個實體，它很可能是一個AR。 AR上的實體可以擁有AR集合嗎？

所以也許它的結構應該是這樣的？

public class Location // is an aggregate Root 
{ 
    public IEnumerable<Field> Fields {get;set;} //in real code encapsulated. not here for brevity 
} 
public class Field // is an Aggregate Root 
{ 
    public Location Location {get;set;} //reference to AR 
    public IEnumerable<Task> Tasks {get;set;} 
    public IEnumerable<Events> Events {get;set;} 
} 
public class Task // is an Aggregate Root 
{ 
    public Field Field {get;set;} // reference to AR 
    public IEnumerable<Employee> Employees {get;set;} 
    public TaskType TaskType {get;set;} // probably Value Object 
    public IEnumerable<Equipment> Equipment {get;set;} // maybe Entity or AR 
}

這使得它更容易處理所修改的最多，穿越它們之間的關係的對象，但感覺有點像老式OOP和AR並不真正意味着什麼。

再次，我是DDD的新手，沒有任何人爲了完整性檢查而運行此操作。請幫助我瞭解這些邊界是如何繪製的，如果是第一種方法，是否有更簡單的方法來處理實體，然後攜帶AR.id，ParentParent.Id，ParentId以及最終的對象感興趣Entity.Id

感謝您的任何想法 [R

來源

2012-06-25 Raif

這是非常結構性的。聚合是交易一致性邊界，而不是您穿過的結構圖。 –

好，在一些谷歌上搜索，我發現這個偉大的系列文章。

http://dddcommunity.org/sites/default/files/pdf_articles/Vernon_2011_1.pdf

去部分2，依此類推只是更改URL中的最後didgit。

在這裏，我發現，很像伊夫指出的，我誤解了聚合和聚合根的目的。原來他們是關於保持相關實體之間的一致性，而不是僅僅捆綁一堆彼此有關係的實體。

所以如果一個字段在任何給定的日子裏只能有3個任務，那麼一個字段就會成爲一個AR的好候選者，因爲如果你只是添加了任務，那麼你很容易在系統中創建一個無效狀態，就好像你必須通過Field上的方法添加一個Task，然後可以很容易地檢查它是否可以接受。

另外一個人想避免巨大的聚合根，因爲他們需要大量的資源來加載，並可能導致併發問題。等等閱讀他們的文章，他們很好地解決我的上述問題

來源

2012-06-25 21:31:38 Raif

我正在建議這一系列的文章。任何啓動DDD的人都應該在藍皮書上閱讀這些內容！附：如果您的問題已經解決，您應該將此標記爲接受的答案:) –

聚合根設計和大小

回答

相關問題