CQ(R)S 使用 RPC 风格 API 而不是 REST
CQ(R)S using RPC-style API instead of REST
我正在做一个基于 PHP/JS 的项目，我想在后端引入领域驱动设计。我发现命令和查询比 CRUD 更能表达我的 public 域，所以我喜欢按照 CQS 原则构建基于 HTTP 的 API。它不是安静的 CQRS，因为我想在命令和查询端使用相同的模型，但是许多原则是相同的。对于 API 文档，我使用 Swagger。
我找到了一篇通过 REST 资源公开 CQRS 的文章 (https://www.infoq.com/articles/rest-api-on-cqrs)。他们使用 5LMT 来区分 Swagger 不支持的命令。此外，通过将 CQS 置于面向资源的 REST API 中，我不会失去 CQS 提供的意图揭示接口的好处吗？我没有找到任何直接通过基于 HTTP 的后端公开命令和查询的文章或产品。
所以我的问题是：直接通过 API 公开命令和查询是个好主意吗？它看起来像这样：
POST /api/module1/command1
GET /api/module1/query1
...
它不会是 REST，但我看不出 REST 如何为 table 带来任何好处。维护 REST 资源会引入另一种模型。此外，在 URL 中包含命令和查询将允许使用路由框架和访问日志等功能。
命令和查询是实现细节。如果您选择了另一种样式，它们将根本不存在，这一点显而易见。
A RESTful API 通常（如果做得对）遵循概念领域模型。 概念领域模型不是实现细节，因为它存在于您的用户头脑中，是您系统需求的来源。
因此，RESTful API 通常更容易理解，因为客户（开发人员）无论如何都必须理解概念领域模型，并且 RESTful 接口遵循概念的这样一个模型。对于基于 API.
的查询和命令，情况并非如此
所以我们要权衡取舍
您已经确定了围绕命令和查询构建 RESTful API 的缺点，我指出了您建议的缺点。我的建议如下：
如果您正在构建 API 其他团队 甚至 客户消费，然后走RESTful的路。客户会更容易理解你的API。
如果，另一方面，API 只是一个内部的，例如由您的团队构建的 JS 前端使用，并且您在 API 上没有外部客户端，那么您建议直接公开命令和查询可以是值得（上述）缺点的捷径。
如果你走捷径，对自己诚实并承认这一点。这意味着一旦您的需求发生变化并且您现在有了外部客户，您可能应该构建一个 RESTful API.
don't I loose the benefit of the intention-revealing interface which
CQS provides by putting it into a resource-oriented REST API?
为谁表露心声？客户端程序员？服务器端程序员？在维护域模型的同一个 team/org 中？在 team/org 之外？互联网上有人会天真地通过使用 OPTIONS 请求探测起始 URI 来访问您的 API 吗？有人可以访问包含 URI 和有效负载结构的完整 API 文档吗？
REST 与 CQRS 正交。最后，无论您如何在 Web 上公开您的资源，域概念都会反映在某个地方，无论是在 URI、有效负载还是媒体类型中。我认为使用 DDD 或 CQRS 不会对您设计 API 的方式产生太大影响。
我正在做一个基于 PHP/JS 的项目，我想在后端引入领域驱动设计。我发现命令和查询比 CRUD 更能表达我的 public 域，所以我喜欢按照 CQS 原则构建基于 HTTP 的 API。它不是安静的 CQRS，因为我想在命令和查询端使用相同的模型，但是许多原则是相同的。对于 API 文档，我使用 Swagger。
我找到了一篇通过 REST 资源公开 CQRS 的文章 (https://www.infoq.com/articles/rest-api-on-cqrs)。他们使用 5LMT 来区分 Swagger 不支持的命令。此外，通过将 CQS 置于面向资源的 REST API 中，我不会失去 CQS 提供的意图揭示接口的好处吗？我没有找到任何直接通过基于 HTTP 的后端公开命令和查询的文章或产品。
所以我的问题是：直接通过 API 公开命令和查询是个好主意吗？它看起来像这样：
POST /api/module1/command1
GET /api/module1/query1
...
它不会是 REST，但我看不出 REST 如何为 table 带来任何好处。维护 REST 资源会引入另一种模型。此外，在 URL 中包含命令和查询将允许使用路由框架和访问日志等功能。
命令和查询是实现细节。如果您选择了另一种样式，它们将根本不存在，这一点显而易见。
A RESTful API 通常（如果做得对）遵循概念领域模型。 概念领域模型不是实现细节，因为它存在于您的用户头脑中，是您系统需求的来源。
因此，RESTful API 通常更容易理解，因为客户（开发人员）无论如何都必须理解概念领域模型，并且 RESTful 接口遵循概念的这样一个模型。对于基于 API.
的查询和命令，情况并非如此所以我们要权衡取舍
您已经确定了围绕命令和查询构建 RESTful API 的缺点，我指出了您建议的缺点。我的建议如下：
如果您正在构建 API 其他团队 甚至 客户消费，然后走RESTful的路。客户会更容易理解你的API。
如果，另一方面，API 只是一个内部的，例如由您的团队构建的 JS 前端使用，并且您在 API 上没有外部客户端，那么您建议直接公开命令和查询可以是值得（上述）缺点的捷径。
如果你走捷径，对自己诚实并承认这一点。这意味着一旦您的需求发生变化并且您现在有了外部客户，您可能应该构建一个 RESTful API.
don't I loose the benefit of the intention-revealing interface which CQS provides by putting it into a resource-oriented REST API?
为谁表露心声？客户端程序员？服务器端程序员？在维护域模型的同一个 team/org 中？在 team/org 之外？互联网上有人会天真地通过使用 OPTIONS 请求探测起始 URI 来访问您的 API 吗？有人可以访问包含 URI 和有效负载结构的完整 API 文档吗？
REST 与 CQRS 正交。最后，无论您如何在 Web 上公开您的资源，域概念都会反映在某个地方，无论是在 URI、有效负载还是媒体类型中。我认为使用 DDD 或 CQRS 不会对您设计 API 的方式产生太大影响。