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