DDD有界上下文“集成”

Question

我们正在尝试为某种情境找出分离的有界上下文集成方案。

假设一个上下文是“文档核心”有界上下文（BC），它有一个“文档”实体，带有一个“作者”。使用IdentityAccessContext BC（如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. 在两个BC之间复制用户的全名？

这两种方法都不太合适，因为#1需要在某个级别上连接来自2个BC的数据，而#2则需要在更改用户名称时可能更新多个BC。

对此应该怎么做？（如果相关的话，使用C#，MVC，NHibernate）

显然，先获取对象列表，然后稍后获取作者的姓名和其他数据是不现实的。

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

- lko

Answer 1

以下是一些可能对您有用的解决方案：

A. 在文档边界上下文中使用冗余属性，例如

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

但这种方法不够灵活，如果查询需求发生变化，模型就必须改变。

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

- Yugang Zhou

Answer 2

与其集成这些有界上下文，您可能希望将它们组合起来。请查看实施 DDD 书籍中“应用程序”章节下的相关部分。

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

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

- fstuijt