DDD,事件存储,UI

Question

我有一个项目,其设计或至少应根据众所周知的DDD原则.

1. 返回 - DDD + CQRS +事件存储

2. UI - ngrx/store

我有很多问题要问,但现在我会坚持这两个:

1. 在执行单个命令/操作后,应如何更新UI存储？

a)订阅response.ok

b)听域名活动

c)触发持有创建/更新/删除对象的通用事件？

2. 在每个命令/事件中将整个聚合根dto与其所有实体一起传输是一个好主意,还是最好有更细粒度的命令/事件,例如:只有一个属性？

Answer 1

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

我的Aggregates中的命令方法返回void(尊重CQS); 因此,接收命令请求的REST端点仅响应类似的内容OK, command is accepted.然后,它取决于在后端服务器中处理命令的方式:

• 如果同步处理命令,那么简单OK, command is accepted就足够了,因为UI将刷新自己并且新数据将在那里;
• 如果异步处理命令然后事情变得更复杂,应该返回某种命令ID,所以响应就像OK, command is accepted and it has the ID 1234-abcd-5678-efgh; please check later at this URI for command completion status

同时,您可以收听域事件.我使用从后端发送到UI的服务器发送事件来执行此操作; 如果UI是基于Web的,这是有用的,因为可能有多个浏览器窗口打开,数据将在后台更新页面; 这很好,客户很高兴.

关于在命令响应中包含读取端的一些数据:这取决于您的具体情况; 我避免它,因为它意味着在写入时读取,这意味着我无法在更高层次上将写入与读取分开; 我希望能够独立地扩展读取部分的写入.所以,a response.ok是最干净的解决方案.此外,它意味着命令/写入端点对调用者做出一些查询假设; 为什么命令处理程序/命令端点应该假定调用者需要什么数据？但是可能存在例外情况,例如,如果您希望减少请求数量,或者在命令发送到后端服务器后使用也执行READ的API网关.

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

我在使用CQRS时从不发送整个聚合; 你有阅读模型,所以每个聚合在每个阅读模型上有不同的表示.因此,您应该为每个UI组件创建一个读取模型,这样您就可以保留并仅发送UI上显示的数据,而不是包含任何人需要在任何地方显示的内容的神似对象.

Answer 2

命令基本上分为两类之一：创建命令和其余命令。

创建命令

使用创建命令，您通常希望取回刚刚创建的对象的句柄，否则您将陷入黑暗，无处可去进一步操作它。

• 我相信 CQS 和 CQRS 中的创建命令可以返回某种标识符或位置：请参阅我的答案。命令处理程序可能会知道该标识符，命令处理程序可以在其响应中返回该标识符。这很好地映射到REST 中的201 Created+Location标头。

• 您还可以让客户端生成 ID。在这种情况下，请参阅下文。

所有其他命令

客户端显然拥有该对象的地址。在从 HTTP 部分获得 OK 后，它可以简单地重新查询其位置。或者，您可以轮询该位置，直到有指示该命令成功为止。它可以是资源版本 ID、Constantin 指出的状态、Atom feed等。

另请注意，命令处理程序返回操作的成功状态可能更简单，这是否真的违反 CQS 是有争议的（再次参见上面的答案）。