Question

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

假设一个上下文是文档核心有界上下文（BC），并且有一个文档实体，带有作者。使用 IdentityAccessContext BC ，就像将{em>用户，组和角色分隔到他们自己的上下文中的Implementing DDD book一样有意义。

正在发生的问题是在考虑提取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个选项，至少后者2没有意义在这种情况下，应用程序是MVC，它直接使用2 BC作为类库，它们都使用相同的数据库。更新用户信息可以通过Identity BC的应用程序服务直接从MVC完成。数据库和BC可以根据需要进行更改。

Answer 1

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

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

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

Answer 2

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

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

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

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

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

DDD有界上下文“整合”

2 个答案: