使用 GraphQL API 的清洁架构 CQRS

Question

我正在开发 API 服务器（ASP.NET Core）。为了防止将来出现意大利面条式代码和其他讨厌的东西，我按照 Clean Architecture/CQRS（使用 MediatR）设计系统。

我正在考虑将 GraphQL 用于 API 而不是 REST（Hot Chocolate GraphQL）。在 HotChocolate GraphQL 的几个示例中，使用 GraphQL-EF 机制直接查询数据库。虽然这似乎是有益的，但我担心从长远来看这可能会使代码复杂化。数据库结构可能会发生变化等。在我看来，API 应该与存储库层保持分离。尽管需要做更多的工作，但我认为 GraphQL 应该与 CQRS 通信。

你的想法，请！

Answer 1

尽管这不是一个封闭式回答“是或否”的问题，但我同意你的观点。我怀疑这些例子中的大多数可能只是为了演示。如果不分离契约、业务逻辑和数据层，似乎很难确保 SOLID 原则。

像您一样使用 CQRS 和 MediatR，您可以更轻松地执行 DDD。因此，命令/查询位于应用程序层似乎很自然，而存储库的实现可以转到基础设施层。另一方面，API 合约将进入表示层。

事实上，我们可以根据我们的业务需求，在应用程序层中不断开发多种功能。这些功能可以提供不同的演示模块、以不同方式公开的 API、UI 应用程序等。另一方面，这些功能可以依赖于各种基础设施例如

Microsoft在这里提供了关于常见 Web 架构的精彩分析，重点关注 Clean Architecture 。

最后，在我看来，是的，您可以在演示文稿中设置 GraphQL API ，在应用程序层中使用 CQRS 设计并使用 MediatR 编排的业务逻辑，以及在基础设施中实现的数据存储库（尊重在应用）。

Answer 2

您是否考虑过将 GraphQL 用于 CQRS 中的 Q 以及用于 CQRS 命令端的其他一些 RPC 机制？

Mark Grenfell 在伦敦 2020 年 NDC 上关于 gRPC 的演讲中强调了在没有 API 版本控制的情况下支持可演化灵活性的重要性，这一点似乎证实了您对数据库模式和 GraphQL 之间紧密耦合的担忧。

NDC 演讲：从 WCF 到 gRPC - Mark Rendle | 国家数据中心会议

以下博客文章演示了如何使用动态类型创建成形实体框架查询。我还没有探索如何将这种技术连接到 GraphQL，但这可能提供了足够的模式抽象。

带有 Entity Framework Core 的 CQRS