Architecture CQR和WebSocket

当我们必须向基于CQR的系统添加推送更新功能时，让“读取”模型负责管理这些推送消息似乎是有意义的。当使用长轮询和服务器事件时（主要是单向的），这很有意义

但是WebSocket是双向持久通道。它是一个已建立的连接，可用于获取推送更新和发送命令。问题是WebSocket连接由于其减少的延迟和状态性，对于自动完成搜索框等许多事情来说变得很方便。乍一看，从技术角度来看，当已经有一个可用的通道就位并准备就绪时，没有理由使用另一个端点（即：HTTP POST接收器）

哪里是启用WebSocket端点的正确位置

• 读取模型：对于客户端推送更新和回答诸如自动完成搜索框之类的查询，它是有意义的，但是如果它接受“写入”，它将再次在同一位置读取和更新模型

• 更新模型：接受客户端输入是有意义的。将推送更新发送到客户端有点意义，因为它们是由其他客户端输入触发的。但这对于请求-响应之类的搜索来说毫无意义，比如自动完成搜索

---

WebSocket是一个基础设施问题。正如您所指出的，它们在某些情况下比原始HTTP有很大的优势，但它们与您的域策略无关
在我们的一个项目中，出于您提到的原因，我们通过WebSocket发送了所有命令和查询（包括可观察的查询），但这是从这些命令的作者和客户端抽象出来的
抛开它们在现代网络堆栈中（稍微）较低的延迟[*]我相信有两个明显的地方可以让它们大放异彩
• 订阅经典的事件发布/子流，例如在聊天系统中，或作为某种用户模型的事件流
• 订阅“可观察的阅读模型”或“流式预测”或“连续查询”或您想称之为它们的任何内容，从而在用户更新时将查询结果（例如，我有多少未读消息）发送给用户

---

[*]像IIS这样的一些容器进行HTTP调用非常昂贵，以至于您不得不进入WebSocket以获得可接受的延迟（即，在该项目中，您提到了如何结束发送命令？通过不同的通道？我们通过WebSocket将它们作为基本RPC发送。套接字上的自定义协议允许同时执行多个命令、查询和可观察查询。好的，那么您将端点放在何处？在读取模型或更新模型中？ah、 我们有一个自己启动的端点（只是一个自托管的web套接字服务器）。然后编写应用程序服务，调用其中一个。当然，大多数命令都会调用更新模型，大多数查询都会调用读取模型。在某种程度上，这就像询问REST服务的HTTP端点是在读取模型中还是在更新模型中。两者都不是——它是基础结构，由您决定如何使用它。你会接到两个都能做到的电话。