当微服务体系结构中的CQRS模式导致整体数据结构时该怎么办

Question

我正在尝试通过实施一个示例项目来学习微服务，试图选择一个半复杂的人，以面对微服务架构中的现实世界挑战。 这是我设计到这里的项目流的简化版本： flow 中所看到的那样

1. 如您在图像 BFF ）将从Frontend获得包含令牌
2. bff 的请求，将通过将其发送给用户MS 的任命授权JWT令牌，
3. 由公司ID，，公司IDS分开因此，在获得约会之前，我需要让用户公司
4. Company ID将被发送到约会以获得公司的约会
5. 约会将检查是否已授权演员要通过其角色获得约会清单（较早来自用户MS ）
6. 的约会列表
7. 约会将返回约会内 请参阅在实体中，我确实具有双方的ID（Sidea，side）
8. bff 将通过用户内部约会数据从ID中获取这些用户详细信息
9. ，这些数据已返回， 客户的ID
10. 有一个客户_id是公司MS 内部 在客户渴望访问的项目中，BFF将发送一个请求，以从项目MS 中获取该项目
11. ，BFF将加入数据并将其返回到Frontend应用程序。

这也是微服务中实体的简化版本： 实体

现在，我正在使用构图API方法来获取我需要的数据，但是AS AS AS AS AS您可以看到流程很复杂，我想不出一种实施分页的方法，因为我可能需要对数据进行分类，过滤然后分页，因此我认为在这种情况下，这可能是一个好主意CQRS模式，但问题是因为我有许多这样的情况，所以我必须实施许多CQRS服务。

我想知道是否可以：

1. 可以创建单个CQRS服务以将所有数据用于阅读目的而不是每种情况的CQRS？
2. 对于这样的某些情况，CQRS读取数据库几乎与Monolith Architecture DB相同。是。这还好吗？
3. 是否有其他方法可以探讨使用部分重复数据创建和管理多个CQRS的复杂性？

Answer 1

CQR将帮助您在一次通话中获取所有必需的详细信息。 CQRS服务将有多个表，这些表是不同的微服务的一部分。

一个示例将是“订单ViewService”需要从“ OrderService”，“ evelyService”，“ counctingService”中收听和存储事件。但是，它不会听取“订单ViewService”不关心的其他多种服务。
因此，我在这里提出的观点是数据库不会变得与整体数据库如此相似，因为它将具有更多的详细信息。

对于您的项目，您可能需要一个可以满足您要求的单个CQR。
似乎您的要求依赖于所有微服务，因此单个CQRS服务可以帮助您解决要求。

另外，如果您担心空间，请确保仅将哪些详细信息保存到视图/读取CQRS数据库。从而确保我们不会为所有服务的所有详细信息压倒DB。

随着应用程序的增长，可以有多个CQRS服务收听不同的服务或服务组合，从而服务其职责。

参考 - https://microservices.io/patterns/patterns/data/data/data/cqrs.html

i认为这是解释的，这是我对CQR的想法。让我知道您是否有任何疑问，将其作为评论发布。