3

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

假设一个上下文是Document Core Bounded Context (BC)，它有一个Document Entity 和Author。在实现 DDD 书中使用IdentityAccessContext BC将用户、组和角色分隔到他们自己的上下文中是有意义的。

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

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

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

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

public class User
{
    long Id;
    string FullName;
}

获取文档列表时，应该如何将来自IdentityAccess BC的信息检索到文档作者/与文档作者一起进行显示（例如全名）？

似乎有几个选择：

  1. 也许是一个从两个表中获取数据的反腐败层？
  2. 在两个BC中重复用户的全名?

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

关于这个还能做什么？（如果重要，使用 C#、MVC、NHibernate）清楚地获取对象列表并稍后获取例如作者的姓名和其他数据是不现实的。

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

4

2 回答 2

1

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

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

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

于 2013-11-27T21:24:12.853 回答
1

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

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

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

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

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

于 2013-11-28T01:13:32.413 回答