我之前发布了一个问题，关于如何在DDD中模拟通知和用户看到这些通知。
链接在这里。是否所有的东西都必须是一个集合？多对多链接
对此进行简单的总结。
我们可以在系统中提出我们想要给用户看的通知(通知会针对某些用户，你定义了一个过滤器，例如：只显示管理员，只显示普通用户，只显示x客户端的用户)。如：只显示管理员，只显示普通用户，只显示x客户端的用户）当用户看到通知时，我们要对其进行标记，使其不会再看到。
帖子上有人提出了一个建议，希望有一个通知汇总，并把对它的引用存储在用户汇总中.这样当一个通知被创建时，事件就会被接收，一个服务会把这个通知添加到它认为合适的用户中。
所以我们在用户中有一个通知列表。
我认为这是一个绑定的上下文（通知绑定的上下文）。当然，如果我把它建模为一个微服务，我会在自己的微服务中处理这个通知的东西。
如果我们要使用微服务，用户创建的事件将来自另一个服务（用户服务）。
问题:通知的创建将在通知微服务中进行。我也会想把用户标记看到通知也放在那个服务里。
因此，在这一点上，通知微服务不会持有一个用户的完整集合，它只会有一个部分，包含；id，通知的集合和任何可能想要过滤的标准。
在一个不属于它的微服务（通知微服务）中拥有一个聚合（可以是部分聚合，因为它只是我们想要的东西），可以吗？
这听起来并不坏，因为它将减少对用户的占用，通过分割部分，并且将这些功能捆绑到处理它的服务中是很好的。
然而，我们是否想把所有用户的东西都放在一个地方，甚至把其他功能也一起放进去？看到一个通知会不会放在用户微服务里（感觉不对）？
谢谢你
简而言之，不要共享聚合体，共享这些聚合体的投射，这些聚合体是代表来自其他约束上下文的聚合体的值对象。
在一个微服务（通知微服务）中拥有一个不属于它的聚合体（是部分聚合体，因为它只是我们想要的东西）可以吗？
你所说的 "部分聚合"，我称之为一个独立BC所拥有的聚合的投影。所以这个投影 可以 由导入的微服务中暴露的BC所拥有。从这个意义上说，是的，它是可以的。
所以本质上，我们在用户微服务中拥有一个用户的集合，而通知的集合。
不，你没有。你在它的BC中拥有User，在Notifications BC中拥有User的投影。一个BC可以拥有其他BC的聚合体的投影，但不能拥有外来聚合体本身。 你只想从其他BC中投射你需要的东西，而不是所有的东西。如果是所有的东西，那么你几乎打破了一些基本的DDD。而且从物理的角度来看，你可能会想共享数据库等等，这就违背了好的微服务架构的一些特点。
问题。通知的创建将在通知微服务中进行。我也很想把用户标记他们已经看到了一个通知也放在那个服务中。
我觉得这样就可以了。从你问题的上下文听起来是这样的（我当然不知道你所做的全部内容）。也许在你的Notifications BC中，你有一个NotifiedUser与一个Notifications的列表，也可能是反过来的SeenNotifications与一个Users的列表。