假设我们有两个业务组件
这拥有用户。当用户信息更改时，此组件会发布消息。例如“NewUserCreated”
处理与用户的通信。电子邮件、推文等。因此该组件订阅用户消息，在其自己的存储中存储该信息的一个子集。
问题
如果 User Management 组件在 Publications 组件之前联机，会发生什么情况？ Publications 如何获取现有用户列表？它不应该知道用户管理组件如何存储其数据。
最佳答案
我不确定用户管理和发布是 BC，而是不同的服务或 AC，因为它们提供不同的业务功能，而不是实体的两个子集。
在 Publications 服务中存储 User 实体的子集可能是一种服务气味。除了关联 ID (userId) 之外，这两个服务之间不应有任何数据重复。
发布服务不需要所有用户的列表:
如果您谈论的是较短的服务器停机时间，如维护或版本更新，那么从 UserManagement 服务发送的消息将在传出队列(或配置超时后的错误队列)中可用，并且可以重新发送到 Publications 服务。以前的数据应该在 Publications 数据存储中。
让我们考虑另一个场景 - 假设您的系统已经运行了一年，并且您一直在收集用户信息，而没有发布服务中的功能。现在，在您拥有数百万用户之后，您可以添加新的发布服务。
最初，那里将没有数据。当系统的当前用户登录时 - 他可能会看到一个新页面，他应该在其中填写他的发布详细信息(电子邮件、推特、Facebook 帐户等)，这将导致发布服务数据中出现一个新条目(带有相关的用户身份)。新用户将在登录时将数据添加到发布服务数据存储(如果您要求他们这样做)。
这有帮助吗？
关于distributed-computing - 在发布者之后在线时为订阅者数据播种，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14226934/