如何破坏同一实体但不同的微服务域

Question

我正在面对一个新的微服务应用程序的案例。

我有一个实体作为用户（一个表，但角色不同）。

考虑我担任 manager 和 reader 的角色，还有一个实体 图书。

经理可以将 Books 分配给阅读者，并且我将微服务称为 usermS ， bookmS 。

当我想获取 Book-A 的所有阅读器时，API将进入 bookmS ，但是用户详细信息是仍然使用 usermS 。

以及组合搜索。

如果图书的 readers 持续增长，我更担心分页并搜索 readers 。预计将来会担任职务。

Answer 1

我对您的问题的看法：

您有2个有界上下文，每个都有一个微服务，并且您必须将它们翻译概念整合在一起：

身份和访问管理（IAM）。这里有用户和角色的概念。

图书馆：这里有管理者和读者的概念，它们是IAM中的角色。

关于搜索和有关读者的信息，例如，在IAM受限的上下文中，您具有登录名和密码，但是IAM不了解读者的其他详细信息。

更新：关于数据重复

在您的评论https://stackoverflow.com/posts/comments/101968503?noredirect=1中，您的意思是在同一BC内跨不同实体的重复数据 ，不是吗？例如，在Reader和Manager实体中有电子邮件吗？您可以使用公共数据来做一个抽象的基础实体，两个实体都从中继承。这是沃恩·弗农（Vaughn Vernon）的书中的方法。

如果您要进行异步集成，则重复数据会存在于不同的BC中。但是没有非规范化，每个BC都有自己的数据库，并且每个数据库都已规范化。

BC图书馆（下游）和IAM BC（上游）在概念上是一致的。 BC省图书馆将侦听IAM BC事件，并将更新其数据库。这意味着应该可以忍受的延迟。关于电子邮件，我不允许对其进行修改，因为它是用户的登录名，但这只是我的看法。

如果您不想跨BC复制数据，或者不能忍受下游BC中的更新延迟，则可以进行同步集成。因此，每次BC图书馆需要IAM BC的数据时，它都会调用IAM BC提供的http rest api，并等待响应。

Answer 2

让我们首先解决您的问题：

从简单的一开始：

当我想获得Book-A的所有读者时，API将加入bookmS，但用户详细信息仍由usermS负责。

您的疑问是如何显示书本中的用户详细信息？

有两种选择：

1. 当某个用户成为您的书的阅读器时，将用户名和详细信息的电子邮件类型保存在bookms的阅读器对象中，以便您可以显示它们，还可以侦听userms的用户详细信息更改事件，以便更新阅读器。

这里的好处是，userms和bookms之间没有依赖关系。 不好的地方是，当用户详细信息更改时，您可能需要更新多个读取器实体，此处的小的优化只是在读取模型中进行更新。

1. 首先从bookms然后从userms获取数据。

好的部分：不监听事件，始终保持一致的数据。 糟糕的部分：bookms和userms之间以及以及合并搜索之间的依赖性很高。

我会采用第一种方法，假设用户不需要经常更改显示数据所需的基本细节。

第二个问题：

如何使用DDD破坏系统？

在此第一个答案中给出了正确的方向。我只想再增加一点。

您应该将经理和读者视为书本中的实体，而不是角色。 来自DDD的原因以及一般而言： 一般而言：用户既可以管理书籍，也可以管理读者。 DDD：Manager和Reader是概念，哪些bookms（实际上应称为libraryms）是域实体的一部分。

因此您的解决方案将是：

用户：

用户：有权访问图书馆并可以申请成为管理员或读者的人。可能有两个角色-学生，管理员。

图书馆： 管理者实体-允许向读者订阅书籍的用户。 ReaderEntity-已订阅书籍的任何用户 BookEntity-代表在图书馆中注册的图书 BookSubscriptionEntity-它是您的选择，您可以使用BookEntity，但是我更愿意这样做。

现在，通过将作为管理员的角色与作为实体的经理分开，您实现了两件事。

现在是一个管理员，也可以是一个读者，一个学生也可以是一个管理员。此外，图书馆微服务根据DDD进行工作，易于理解，并且一些API（如将书分配给读者）需要检查userms的所有内容