我了解REST +事件采购的基础知识。 我从未使用过严格的RESTful API，也没有参与任何Event Sourcing项目。
有人可以解释两者是否可以一起使用？
在事件源中，客户端发送事件，这是否意味着在服务器上有一个事件集合，API的所有POST都将在该集合上，以向其添加事件？
客户端如何发现它可以发送到服务器的命令？
我了解REST +事件采购的基础知识。 我从未使用过严格的RESTful API，也没有参与任何Event Sourcing项目。
有人可以解释两者是否可以一起使用？
在事件源中，客户端发送事件，这是否意味着在服务器上有一个事件集合，API的所有POST都将在该集合上，以向其添加事件？
客户端如何发现它可以发送到服务器的命令？
有人可以解释两者是否可以一起使用？
是。客户端（浏览器）只是做它想做的事情，（http）服务器可以将这些动作记录为事件。
在事件源中，客户端发送事件，这是否意味着在服务器上有一个事件集合，API的所有POST都将在该集合上，以向其添加事件？
不可以。客户端可以是事件的发起者，但不应该知道什么构成事件，以防止服务器和客户端之间基于事件集合的紧密耦合。事件采购应该被封装并且对于演员来说是隐藏的。
客户端如何发现它可以发送到服务器的命令？
如果您不需要在上一个问题中建议的同一集合上发送事件，则无需这样做。您可以以任何您想要的方式发布REST API，并隐藏来自客户端/ actor的事件源。看一下 http://restdesc.org/。
有人可以解释两者是否可以一起使用？
是。客户端（浏览器）只是做它想做的事情，（http）服务器可以将这些动作记录为事件。
在事件源中，客户端发送事件，这是否意味着在服务器上有一个事件集合，API的所有POST都将在该集合上，以向其添加事件？
不可以。客户端可以是事件的发起者，但不应该知道什么构成事件，以防止服务器和客户端之间基于事件集合的紧密耦合。事件采购应该被封装并且对于演员来说是隐藏的。
客户端如何发现它可以发送到服务器的命令？
如果您不需要在上一个问题中建议的同一集合上发送事件，则无需这样做。您可以以任何您想要的方式发布REST API，并隐藏来自客户端/ actor的事件源。看一下 http://restdesc.org/。
REST是一种交付方法，它决定了应用程序的界面。您主要使用REST与即时一致性模型，但它可以通过响应202接受命令来支持最终一致性模型。
事件源是一种通用的数据存储机制。您通常使用事件源，最终的一致性模型以及域驱动设计，命令和查询隔离，但它可以通过多阶段提交支持立即一致性模型。
它们在您的应用程序中解决了完全不同的问题，并且它们彼此兼容，因此您可以将它们一起使用。
在事件采购中，客户端发送事件，这是否意味着 服务器有一个事件的集合和所有的POST API将在该集合上，为其添加事件？
你完全误解了这个概念。您可以将事件序列存储在事件存储中。事件是状态更改，因此如果您存储应用程序的每个状态更改并以正确的顺序重放它，则可以重新创建应用程序的当前状态。这非常好，因为您可以通过重放事件并将其转换为数据库查询来将数据迁移到另一个数据库。您可以使用常规数据库创建查询缓存。因此，您的客户端可以读取该查询缓存，而不是始终从场地重新创建当前状态。
事件通常不是由客户创建的。通过域驱动设计，域逻辑可以通过处理命令来创建域事件。
客户端如何发现它可以发送到服务器的命令？
通过REST，客户端使用链接将请求发送到REST服务。 REST服务可以处理这些请求并将其转换为命令和查询。这些命令由域逻辑处理，并将导致提升域事件。查询将转换为解决查询缓存的数据库查询。
简短回答 - 是的，我们可以。
您列举的所有内容，我的意思是REST，ES和CQRS用于不同的目的。 所以我没有看到任何问题一起抓住它。
让我们看看 - REST是一种做Web服务API的方式，ES是一种在域内进行通信的工具，而CQRS则是一种中级架构。
好吧，在ES中，客户端（如果我们谈论的是Web客户端）不会发送域事件。如果你的意思是另一个BC并且BC是你域名的一部分，我想运输事件应该通过另一种方式解决，a 服务巴士 或类似的东西会很大。如果BC不是您域的一部分，您应该通过ACL和API进行通信，而不是原始域事件。 :)
简短的命令。同样，在CQRS中，命令存在于应用程序边界内。外部客户端（Web客户端，api客户端）不应该具有直接发送应用程序命令的能力。您应该提供一个API（内部客户端），它允许执行某些服务的用例，但不允许单个和单独的命令。对于自制示例，您可以尝试在非常受欢迎的SO问题上获得答案 - 如何在使用CQRS时检查用户名uniques？ :)