DDD有界上下文「集成」

我們試圖找出場景中分離的有界上下文集成。DDD有界上下文「集成」

說一個上下文是文獻核心界上下文（BC）並且具有文獻實體，與作者。使用IdentityAccessContextBC如在Implementing DDD book中將用戶，組和角色分隔成它們自己的上下文是有意義的。

發生的問題是當考慮獲取說100+文檔的列表。

說文檔核心BC有它自己的實體來標記文檔的作者。

public class Author 
{ 
    long Id; // Same as UserId 
    long Document; 
}

然後標識BC 有相關信息的用戶。

public class User 
{ 
    long Id; 
    string FullName; 
}

當獲取的文獻列表，如何從IdentityAccessBC應該被檢索到/與文檔作者用於顯示（例如姓名）的信息？

似乎有是幾個選擇：

既然＃1需要連接來自公元前2年的數據，而＃2需要在更改用戶名時潛在更新幾個BC，否則感覺不太對。

可以做些什麼呢？（使用C＃，MVC，NHibernate（如果有的話））清楚地獲取對象列表並稍後獲取例如以後作者的名字和其他數據是不現實的。

當在BC整合看，但是，鑑於在書中RPC，域事件，和RESTful服務集成提到的3個選項中，至少後者2不要在這種情況下有意義，其中應用程序是MVC，它直接使用2 BC作爲類庫，它們都使用相同的數據庫。更新用戶信息可以直接從MVC通過身份BC的應用程序服務完成。數據庫和BC可以根據需要更改。

2013-11-14 lko

而不是整合這些有界的上下文，你可能會想要組成它們。查看實施DDD書中「應用」一章下的相關章節。

一種方法是創建一個應用程序服務，該服務可以訪問兩個有界的上下文並創建一個包含來自兩個BC的信息的Document DTO。

你甚至可以進一步爲它創建第三個有界的上下文，並使用衆所周知的BC集成技術來保持這個新的BC同步（消息傳遞，夜間批量等）。正如Vaughn Vernon在他的書中指出的那樣，這可能會在這個新的BC中產生貧血域模型。

2013-11-27 21:24:12 fstuijt

一些解決方案，您可能感興趣的：

A.在文件界環境中使用多餘的屬性。像

public class Author { 
    long Id; // Same as UserId 
    string fullname://redundant 
    long Document; 
}

但是這一個是不靈活的，如果查詢需求改變，模型不得不改變。

B.域模型不擅長查詢，如果您熟悉CQRS，更好的解決方案是構建一個單獨的查詢組件。

2013-11-28 01:13:32 Hippoom

回答