在DDD中查詢多個存儲庫中的數據

例如

public class OrderAggregate 
{ 
    public int ID {get;set;} 
    public string Order_Name {get;set;} 
    public int Created_By_UserID {get;set;} 
} 

public class UserAggregate 
{ 
    public int ID {get;set;} 
    public string Username {get;set;} 
    public string First_Name {get;set;} 
    public string Last_Name {get;set;} 
}

我使用SQL關係數據庫中，以堅持域對象。每個聚合根都匹配一個存儲庫。

如果我想查找由John Doe創建的訂單（按多個總計進行查找），那麼DDD的方式是什麼？

添加FIRST_NAME和另外姓氏爲OrderAggregate爲了增加FindByUserFirstLastName方法OrderRespository，但可能引起兩個總根源
之間的數據一致性問題，創建一個原始的SQL查詢和訪問DB直接以跨度搜索翻過「庫」
使用「發現者」，以直接從DB
加入實體
複製數據necessa RY查詢完成到一個新的聚集根如

public class QueryOrderAggregate 
{ 
    public int ID { get; set; } 
    public string Order_Name { get; set; } 
    public int Created_By_UserID { get; set; } 
    public string First_Name { get; set; } 
    public string Last_Name { get; set; } 
}

來源

2017-07-07 mko

不要讓數據庫模型決定了你的域模型 – MJK

你有兩個限定語境：訂購和UserManagement –

@ConstantinGALBENU不，那是錯誤的解釋 – mko

在情況下，我想找到被李四（SEACH翻過多聚集）創建訂單什麼會是DDD的方式嗎？

差不多，它去與存取總以同樣的方式...

您創建一個存儲庫，它提供了（對於這種觀點無論名稱/報告是您的域名）。它可能使用UserId作爲識別報告的關鍵。在存儲庫的實現中，實現可以做任何有意義的事情 - SQL連接是一個合理的起點。

查看/報告基本上是一種值類型;它是不可變的，並且可以提供數據，但不具有任何方法或對聚合根的任何直接訪問。例如，該視圖可能包含OrderId，但要實際獲得訂單聚合根，您必須調用上的方法存儲庫。

跨越多個聚合的視圖是完全可以接受的，因爲您實際上不能使用視圖修改任何內容。基礎狀態的變化仍然通過聚合根，這提供了一致性保證。

該視圖是數據的陳舊快照的表示。消費者不應該期待它更新 - 如果你想要更新的東西，請回到版本庫以獲得新的副本。

來源

2017-07-07 15:35:01 VoiceOfUnreason

在DDD中查詢多個存儲庫中的數據

回答

相關問題