3

假设我们有两个业务组件

  1. 用户管理

这拥有用户。当用户信息发生变化时,该组件会发布消息。例如“NewUserCreated”

  1. 出版物

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

问题

如果用户管理组件在发布组件之前上线会发生什么?Publications 如何获取现有用户的列表?它不应该知道用户管理组件如何存储其数据。

4

3 回答 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 回答