DDD、事件存储、UI

执行单个命令/操作后,应如何更新UI存储?

我的聚合中的命令方法返回void(关于CQS);因此,接收命令请求的其余端点只响应如下内容 OK, command is accepted . 然后,这取决于命令在后端服务器内的处理方式:

• 如果同步处理命令 好,接受命令
• 如果命令是异步处理的 然后事情会变得更复杂,应该返回某种命令ID,因此响应如下 OK, command is accepted and it has the ID 1234-abcd-5678-efgh; please check later at this URI for command completion status

Server sent events 从后端发送到UI;如果用户界面是基于web的,这很有用,因为可能会打开多个浏览器窗口,并且数据将在后台更新页面;很好,客户很满意。

关于在命令响应中包含来自读取端的一些数据:这取决于您的具体情况;我避免它,因为它意味着写作时阅读,这意味着我不能在更高的层次上把写和读分开;我希望能够独立地扩展读写部分。所以,a response.ok

将整个聚合根dto与其在每个命令/事件中的所有实体一起传输是一个好主意,还是最好为例如:使用单个属性的命令/事件提供更细粒度的命令/事件?

使用CQR时,我从不发送整个聚合;您有读取模型,因此每个聚合在每个读取模型上都有不同的表示。因此,您应该为每个UI组件创建一个读取模型,这样您就可以保持&只发送显示在用户界面上的数据,而不发送包含任何人需要在任何地方显示的任何内容的类似上帝的对象。

创建命令

使用创建命令时,您通常希望获得刚刚创建的对象的句柄,否则您将处于黑暗中,没有地方进一步操作它。

• 我相信在CQS和CQR中创建命令 可以 my answer here . 该标识符可能由命令处理程序知道,该处理程序可以在其响应中返回该标识符。这很好地映射到 201 Created + Location 收割台处于静止状态。

• generate the ID . 在这种情况下,请参见下文。

所有其他命令

客户端显然具有对象的地址。在从HTTP部分获得OK后,它可以简单地重新查询其位置。或者,您可以轮询该位置,直到有迹象表明该命令成功。它可能是一个资源版本id,一个康斯坦丁指出的状态,一个 Atom feed 等

还请注意,命令处理程序返回操作的成功状态可能更简单,但这是否真的违反了CQS仍有争议(同样,请参阅上面的答案)。

将整个聚合根dto与all一起传输是一个好主意吗 它的实体在每个命令/事件中,或者最好有更多

事实上,最好有粒度命令和事件。 命令和事件应该是不可变的、可表达的对象,能够清楚地表达意图或过去的业务事件。如果对象恰好包含即将更改或已更改的数据,则这种方法效果最佳。