假设我们有两个业务组件
- 用户管理
这拥有用户。当用户信息发生变化时，该组件会发布消息。例如“NewUserCreated”
- 出版物
处理与用户的通信。电子邮件、推文等。因此，该组件订阅了用户消息，并将该信息的子集存储在其自己的存储中。
问题
如果用户管理组件在发布组件之前上线会发生什么？Publications 如何获取现有用户的列表？它不应该知道用户管理组件如何存储其数据。
问问题
150 次
3 回答
5
我不确定用户管理和发布是 BC，而是不同的服务或 AC，因为它们提供不同的业务功能，而不是实体的两个子集。
在发布服务中存储用户实体的子集可能是一种服务气味。两个服务之间不应该有任何数据重复，除了关联 ID (userId)。
发布服务不需要所有用户的列表：
如果您谈论的是较短的服务器停机时间，例如维护或版本更新，则从 UserManagement 服务发送的消息将在传出队列（或配置超时后的错误队列）中可用，并且可以重新发送到 Publications 服务。以前的数据应该在 Publications 数据存储中。
让我们考虑另一种情况 - 假设您的系统已经运行了一年，并且您一直在收集用户信息，但没有发布服务中的功能。现在，在您拥有数百万用户之后，您可以添加新的发布服务。
最初，那里不会有数据。当系统的当前用户登录时 - 他可能会看到一个新页面，他应该在其中填写他的发布详细信息（电子邮件、推特、脸书帐户等），这将导致发布服务数据中的新条目（带有相关的用户身份）。新用户将在登录时将数据添加到发布服务数据存储（如果您要求他们这样做）。
这有帮助吗？
于 2013-01-09T11:34:05.440 回答
1
与任何集成项目一样，我只会选择 ETL 程序，以便在新系统启动之前获取所需的相关数据。
这是一次性的事情，所以没有必要使事情复杂化:)
于 2013-01-09T10:57:52.260 回答
0
正如 moranlf 所说，用户管理和发布似乎是两种不同的服务。两者之间不应有数据重复。
出版物就像著名的亚马逊类比中的运输服务：它保存有关用户实体（地址）的数据，但只有它自己的/它负责的那个（来自 userId 的 appart，这对它们两者都是通用的）。从用户管理服务发布的任何事件都不会将数据“创建”到订阅服务中。它可能会启动一个策略/传奇，触发一个处理程序，但仅此而已。
这里有两种情况：
- 您已经将订阅存储在数据存储中，并且您正在尝试将职责拆分为两个独立的服务。由于 Publications 服务只保存自己的数据，因此它只是将数据从一个表/持久性存储移动到另一个。无需重播或生成事件。
- 您没有订阅：在这种情况下无事可做，因为它会在用户采取行动时存储其数据。
这有帮助吗？
于 2013-01-09T20:46:16.200 回答