fis*_*man 1 rest rpc domain-driven-design cqrs
我正在一个基于PHP / JS的项目中，在这里我想在后端介绍域驱动设计。我发现命令和查询比CRUD是表达我的公共领域的更好方法，因此我喜欢遵循CQS原则构建基于HTTP的API。这不是安静的CQRS，因为我想在命令和查询端使用相同的模型，但是许多原理是相同的。对于API文档，我使用Swagger。
我找到了一篇文章，该文章通过REST资源（https://www.infoq.com/articles/rest-api-on-cqrs）公开了CQRS 。他们使用5LMT来区分不同的命令，而Swagger不支持。此外，通过将CQS放到面向资源的REST API中，我是否不会失去意图显示接口的好处？我没有找到任何文章或产品直接通过基于HTTP的后端公开命令和查询。
所以我的问题是：直接通过API公开命令和查询是否是一个好主意。它看起来像这样：
POST /api/module1/command1
GET /api/module1/query1
...
它不是REST，但我看不到REST如何为表带来任何好处。维护REST资源将引入另一个模型。而且，在URL中具有命令和查询将允许使用诸如路由框架和访问日志之类的功能。
命令和查询是实现细节。从以下事实可以明显看出，如果您选择其他样式，它们将根本不存在。
RESTful API通常（如果操作正确）遵循概念域模型。概念域模型不是实现细节，因为它在用户头脑中，并且是系统需求的来源。
因此，RESTful API通常更容易理解，因为客户端（开发人员）无论如何都必须理解概念性领域模型，并且RESTful接口遵循此类模型的概念。对于基于查询和命令的API，情况并非如此。
您已经确定了围绕命令和查询构建RESTful API的弊端，我指出了您的建议的弊端。我的建议如下：
如果您要构建供其他团队甚至客户使用的API，请采用RESTful方式。客户端将更容易理解您的API。
另一方面，如果该API仅是内部的，例如由您的团队构建的JS前端使用的，并且您在该API上没有外部客户端，那么您建议直接公开命令和查询可以是值得（上述）缺点的捷径。
如果您使用该快捷方式，请对自己诚实，并承认这一点。这意味着只要您的需求发生变化并且现在有了外部客户端，就应该构建一个RESTful API。