c# - 使用没有分离的服务和存储库的 CQRS 真的会影响代码质量吗？

Question

我想问一个WEB Api架构。我的项目由几个 DDD、CQRS(无 ES)微服务组成。每个服务都有域、应用程序、基础设施和 UI 层。在这个例子中，我将使用 BikeMicroservice。它在 UI 层有 BikeController，它向 MediatR 发送命令或查询对象。在应用层中，我定义了使用相同 BikeService 对象来执行 C/Q 的处理程序(对于每个 C 或 Q)。此外，BikeService 有 BikeRepository，它也使用 EF Core DbContext 对象执行命令和查询。
它是一个合适的 CQRS 设备吗？
我担心服务和存储库对象是否真的应该同时执行查询和命令。我在我的项目中观察到的唯一优势是更薄的 Controller (仅发送查询或命令)。
如何升级微服务的架构？
我应该将 DAL 和服务划分为例如使用 EF Core 的 BikeCommandRepository 和使用 Dapper 的 BikeQueryRepository 吗？

Answer 1

马丁福勒 describes several scenarios CQRS 可能对您有益的地方，以及一些会使事情复杂化的地方:

• CQRS fits well with event-based programming models. It's common to see CQRS system split into separate services communicating with Event Collaboration. This allows these services to easily take advantage of Event Sourcing.
• Having separate models raises questions about how hard to keep those models consistent, which raises the likelihood of using eventual consistency.
• For many domains, much of the logic is needed when you're updating, so it may make sense to use EagerReadDerivation to simplify your query-side models.
• If the write model generates events for all updates, you can structure read models as EventPosters, allowing them to be MemoryImages and thus avoiding a lot of database interactions.
• CQRS is suited to complex domains, the kind that also benefit from Domain-Driven Design.

这些是您在决定是否迁移到 CQRS 架构模型时应该评估的一些注意事项。