问题描述
背景:
解释 CQRS 的图表通常会清楚地分离读写路径和单向数据流，就像在这个例子中一样(来源:
Diagrams explaining CQRS usually will have clear separation of read and write paths and one-way data flow, like in this example (source :
问题:
我想澄清一下，
如果后端执行命令需要从数据库中获取一些数据，
If a Command execution in back-end requires some data from the database,
- 写入端"是否应该有一些从写入数据库读取的能力?
- 还是应该完全依赖读取端"进行任何读取?
- 或者命令应该包含调用者提供的所有需要的数据来完成?
推荐答案
可能——加载将要运行命令的实体的最直接方法是从写入数据库"读取其状态.例如，在事件源架构中，更新事件源实体的命令通常通过从写入模型加载该实体的历史记录、从该历史记录中重新组合实体、评估该命令并将新更改附加到历史记录来处理.
Probably -- the most straight forward way to load the entity that is going to be running the command is by reading its state from the "write database". For instance, in event sourced architectures, a command to update an event sourced entity is typically handled by loading the history of that entity from the write model, rehydrating the entity from that history, evaluating the command, and appending new changes to the history.
读取有关未处理命令的实体的状态是另一回事——ddd 词汇在这里有帮助；您正在修改的状态恰好属于一个聚合，只要有可能，就应该将位于聚合之外的状态传递给模型，而不是获取.
Reading state about entities that are not handling the command is a different matter -- the ddd vocabulary helps here; the state you are modifying belongs to exactly one aggregate, state that lives outside of the aggregate should be passed to the model, rather than fetched, whenever it is possible to do so.
这可能意味着远程客户端需要提供数据，或者可能意味着处理命令的应用程序获取所需的读取模型并提供答案.有许多不同的问题会影响您在此处做出的选择
That could mean that the remote client needs to provide the data, or it could mean that the application handling the command fetches the required read model and provides the answer. There are a number of different concerns which can drive the choice you make here
- 如果客户端在生成命令时使用的读取模型与应用在处理命令时使用的视图明显不同，则存在一定风险.
- 保持稳定的 API 使您可以自由地重新设计模型中的聚合边界，而无需更新客户端).
所以没有最好的答案，只是在不同的关注点之间进行权衡.
So no one best answer, just trade offs between different concerns.
最近出现了后者的一个例子——如果您的商业模式要求某些命令需要特定用户的权限，那么我们不应该从表面上获取客户的命令；我们需要应用程序验证命令发布者的身份，然后将该身份的表示传递给模型，以便它可以确定要采取的操作.
A recent example of the latter came up -- if your business model requires that some commands require the authority of a specific user, then we shouldn't be taking the commands from the client at face value; we need the application to verify the identity of the command issuer, and then passing a representation of that identity to the model so that it can determine what action to take.
这篇关于从 CQRS 中写入端的数据库读取数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！