DDD，事件存储，UI [英] DDD, Event store, UI

问题描述

我有一个设计而成的项目，或者至少应该按照众所周知的DDD原则进行设计.

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

2. UI-ngrx/store

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

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

a)订阅response.ok

b)听域事件

c)触发一个包含已创建/已更新/已删除对象的通用事件?

2. 在每个命令/事件中将整个聚合根dto及其所有实体都转移是一个好主意，还是最好在例如单个属性的情况下使用更精细的命令/事件?

解决方案

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

我的聚合中的命令方法返回空值(尊重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

同时，您可以收听域事件.我使用服务器发送的事件来执行此操作从后端发送到用户界面的内容；如果用户界面是基于Web的，则这很有用，因为可能会打开多个浏览器窗口，并且数据将在后台更新页面；很好，客户很满意.

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

在每个命令/事件中将整个聚合根dto及其所有实体都转移是一个好主意，还是最好在例如单个属性的情况下使用更精细的命令/事件?

使用CQRS时，我从不发送整个汇总；您拥有读取模型，因此每个聚合在每个读取模型上都有不同的表示形式.因此，您应该为每个UI组件创建一个读取模型，通过这种方式，您只保留并发送UI上显示的数据，而不发送任何包含任何人都需要在任何地方显示的内容的类似上帝的对象.

I have a project which is designed or at least should be according to the well known DDD principles.

1. Back - DDD + CQRS + Event Store

2. UI - ngrx/store

I have a lot of questions to ask about it but for now I will stick to these two:

1. How should the UI store be updated after a single Command/Action is executed ?

a) subscribe to response.ok

b) listen to domain events

c) trigger a generic event holding the created/updated/removed object ?

2. Is it a good idea to transfer the whole aggregate root dto with all its entities in each command / event or it is better to have more granular commands / events for ex.: with only a single property ?

解决方案

How should the UI store be updated after a single Command/Action is executed ?

The command methods from my Aggregates return void (respecting CQS); thus, the REST endpoints that receive the command requests respond only with something like OK, command is accepted. Then, it depends on how the command is processed inside the backend server:

• if the command is processed synchronously then a simple OK, command is accepted is sufficient as the UI will refresh itself and the new data will be there;
• if the command is processed asynchronously then things get more complicated and some kind of command ID should be returned, so a response like OK, command is accepted and it has the ID 1234-abcd-5678-efgh; please check later at this URI for command completion status

At the same time, you could listen to the domain events. I do this using Server sent events that are send from the backend to the UI; this is useful if the UI is web based as there could be more than one browser windows open and the data will be updated in the background for pages; that's nice, client is pleased.

About including some data from the read side in the command response: this is something that depends on your specific case; I avoid it because it implies reading when writing and this means I can't separate the write from the read on a higher level; I like to be able to scale independently the write from the read part. So, a response.ok is the cleanest solution. Also, it implies that the command/write endpoint makes some query assumptions about the caller; why should a command handler/command endpoint assume what data the caller needs? But there could be exceptions, for example if you want to reduce the number of request or if you use an API gateway that do also a READ after the command is send to the backend server.

Is it a good idea to transfer the whole aggregate root dto with all its entities in each command / event or it is better to have more granular commands / events for ex.: with only a single property ?

I never send the whole Aggregate when using CQRS; you have the read-models so each Aggregate has a different representation on each read-model. So, you should create a read-model for each UI component, in this way you keep&send only the data that is displayed on the UI and not some god-like object that contains anything that anybody would need to display anywhere.

这篇关于DDD，事件存储，UI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！