我早些时候发布了一个问题，关于如何在DDD中对通知以及用户看到的通知进行建模。
链接到这里：Does everything have to be an aggregate? Many-to-Many Link
有关此内容的简短摘要：
我们可以在系统中向我们显示用户的通知。 （通知将针对您定义过滤器的某些用户。例如，仅显示管理员，仅显示普通用户，仅显示x客户端的用户） 当用户看到通知时，我们希望对其进行标记，以使他们不再看到它。
有人建议对帖子进行汇总，然后将其引用存储在User汇总中。 因此，当创建通知时，事件将被接收，服务会将该通知添加到看起来合适的用户中。
所以我们在用户中有一个通知列表。
我认为这是一个有界上下文（通知有界上下文）。当然，如果我将其建模为微服务，则可以在其自己的微服务中处理此通知内容。
如果我们要使用微服务，则用户创建的事件将来自另一个服务（用户服务）。
问题： 通知创建将进入通知微服务。我也很想把用户标记为他们在该服务中也看到了通知。
因此，在这一点上，通知微服务将无法容纳一个完整的用户集合，而只有一部分，包含； id，通知的收集以及任何可能要过滤的条件
在微服务（通知微服务）中拥有一个不属于它的聚合（可以是一部分，因为它只是我们想要的东西）是否可以？ 因此，从本质上讲，我们在用户微服务中拥有一个用户集合，而在通知中则是一个集合。
这听起来还不错，因为它将通过拆分零件来减少用户的占用空间，并且很高兴将此功能捆绑到处理它的服务中。
但是我们要将所有用户资料保留在一个地方吗？甚至它还具有其他功能？可以在用户微服务中看到通知吗（感觉不对）
谢谢
答案 0 :(得分：2)
简而言之，不要共享聚合，而要共享这些聚合的投影，这些投影是表示来自其他有界上下文的聚合的值对象。
在微服务（通知微服务）中拥有一个不属于它的聚合（可以是一部分，因为它只是我们想要的东西）可以吗？
您所说的“部分集合”是指一个独立的BC拥有的集合的投影。因此，此预测 可以归于在导入微服务中公开的BC。从这个意义上讲，没关系。
因此，从本质上讲，我们在用户微服务中有一个用户集合，而在通知中则是一个集合。
不，你不知道。您在其BC中有用户，并且在通知BC中有该用户的投影。一个BC可以拥有其他BC的合计的投影，但不能拥有外国合计本身。您只想从其他BC投影您所需的内容，而不是全部。如果这是全部，那么您已经破坏了一些基本的DDD。从物理角度来看，您可能会倾向于共享数据库等，这违背了良好的微服务体系结构的某些特征。
问题：通知创建将进入通知微服务。我也很想把用户标记为他们在该服务中也看到了通知。
我认为可以。从您的问题的上下文来看，这听起来像是这样（我当然不知道您在做什么的全部内容）。也许在您的Notifications BC中，您有一个NotificationUser和一个Notifications列表，或者绕过SeenNotifications和一个Users列表。