DDD有界上下文“集成”答案

【问题标题】：DDD Bounded Context "integration"DDD有界上下文“集成”
【发布时间】：2013-11-27 13:26:47
【问题描述】：

我们正在尝试为一个场景找出分离的有界上下文集成。

假设一个上下文是 Document Core 有界上下文(BC) 并且有一个 Document 实体和一个 Author时间>。在Implementing DDD book 中使用IdentityAccessContext BC 将用户、组和角色 分隔到它们自己的上下文中是有意义的。

正在发生的问题是在考虑获取 100 多个文档的列表时。

假设文档核心 BC 有自己的实体来标记文档的作者。

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

然后身份 BC 有一个具有相关信息的用户。

public class User
{
    long Id;
    string FullName;
}

当获取 Documents 列表时，应该如何将来自 IdentityAccess BC 的信息检索到/使用 用于显示的文档作者（例如全名）？

似乎有几个选择：

也许是一个从两个表中获取数据的防损坏层？
在两个BC中重复用户的全名？

感觉都不太对，因为 #1 需要加入来自 2 个 BC 的数据（在某种程度上），而 #2 可能需要在更改用户名时更新多个 BC。

对此可以做些什么？（如果重要的话，使用 C#、MVC、NHibernate）清楚地获取对象列表，然后再获取例如作者的名字和后来的附加数据是不现实的。

然而，在查看 BC 集成时，鉴于 RPC、域事件和 RESTful 服务集成一书中提到的 3 个选项，至少后两个没有意义在这种情况下，应用程序是 MVC，它直接使用 2 个 BC 作为类库，并且它们都使用相同的数据库。可以通过 Identity BC 的 应用服务直接从 MVC 更新用户信息。可以根据需要更改数据库和 BC。

【问题讨论】：

标签： c# asp.net-mvc domain-driven-design bounded-contexts

【解决方案1】：

您可能想要组合它们，而不是集成这些有界上下文。查看实施 DDD 书中“应用程序”一章下的相关部分。

一种方法是创建一个访问两个有界上下文的应用程序服务，并创建一个包含来自两个 BC 的信息的文档 DTO。

您甚至可以更进一步，为其创建第三个有界上下文，并使用众所周知的 BC 集成技术来保持这个新的 BC 同步（消息传递、夜间批处理等）。正如 Vaughn Vernon 在他的书中指出的那样，这可能会导致这个新的 BC 中出现贫乏的领域模型。

【讨论】：

【解决方案2】：

您可能感兴趣的一些解决方案：

A.在文档有界上下文中使用冗余属性。喜欢

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

但是这个不灵活，如果查询需求发生变化，模型必须改变。

B.领域模型不擅长查询，如果你熟悉 CQRS，更好的解决方案是构建一个单独的查询组件。

【讨论】：