订阅者数据在发布者上线后播种

Question

假设我们有两个业务组件

1. 用户管理

这拥有用户。更改用户信息时，此组件将发布消息。例如＆＃34; NewUserCreated＆＃34;

1. 的出版物

处理与用户的通信。电子邮件，推文等。因此，该组件订阅用户消息，将该信息的子集存储在自己的商店中。

问题

如果用户管理组件在出版物组件之前联机，会发生什么？出版物如何获得现有用户列表？它不应该知道用户管理组件如何存储其数据。

Answer 1

我不确定用户管理和出版物是BC，而是不同的服务或AC，因为它们提供不同的业务功能，而不是两个实体子集。

在Publications服务中存储User实体的子集可能是服务气味。除了相关id（userId）之外，两个服务之间不应存在任何数据重复。

发布服务不需要所有用户的列表：

如果您正在谈论维护或版本更新等服务器停机时间短，那么从UserManagement服务发送的消息将在传出队列（或配置的超时后的错误队列）中可用，并且可以重新发送到Publications服务。以前的数据应该在出版物数据存储中。

让我们考虑另一种情况 - 假设您的系统已经运行了一年，并且您一直在收集用户信息而没有发布服务中的功能。现在，在拥有数百万用户之后，您可以添加新的发布服务。

最初，那里没有数据。当系统的当前用户登录时 - 他可能会看到一个新页面，他应该填写他的出版物详细信息（电子邮件，推特，facebook帐户等），这将导致出版服务数据中的新条目（与相关用户身份）。新用户在登录时会向发布服务数据存储添加数据（如果您需要这样做）。

这有帮助吗？

Answer 2

与任何集成项目一样，我只需选择ETL程序即可在新系统启动之前获取所需的相关数据。

这是一次性的事情所以不需要使问题复杂化：）

Answer 3

正如moranlf所说，用户管理和出版物似乎是两种不同的服务。 两者之间不应存在数据重复。

出版物就像众所周知的亚马逊类比中的航运服务：它包含有关用户实体（地址）的数据，但只有它自己/它负责的数据（来自userId的appart，这两者都是共同的他们）。从用户管理服务发布的任何事件都不会将数据“创建”到订阅服务中。它可能会启动策略/传奇，触发处理程序，但仅此而已。

这里有两种情况：

• 您已经将订阅存储在数据存储中，并且您尝试将响应能力分成两个单独的服务。由于Publications服务只保存自己的数据，因此只是将数据从一个表/持久性存储移动到另一个表/持久性存储。无需重播或生成事件。
• 您没有订阅：在这种情况下无需执行任何操作，因为它会在用户执行操作时存储其数据。

这有帮助吗？