CQR在哪里查询业务逻辑/内部流程
我目前正在考虑实施由事件（尚未事件采购）驱动的CQRS进行工作；原因是：
- 我需要汇总数据来支持此服务中出来的RESTAPI（将用于填充视图） - 但是，应用程序逻辑/处理不会使用汇总数据（即本服务以外的数据， 我需要将起源于其中的汇总的位
- 传输到其他系统，以便它们可以对数据做出反应（将产生Kafka主题，因此该系统的“读取”/“投影”侧将消耗与外部系统相同的事件，从这些KAFKA主题中，
- 以帮助填充第一点（即它的数据和他人的数据）的观点的总填充物
我将消费内部系统中的事件， 目前是a）我们在时间紧缩中，而b）由于仍在学习。话虽如此，这是我们将来要做的事情 - 尽管目前，我们在系统的“命令”方面有一个静态的DB，这将仅存储当前状态，
我对此我对使用聚合数据提供REST API；但是，当我想从系统内更改资源（例如，每天触发5次的Cron作业）时，我的困惑来自：
- 如果我有X类资源（给出了一些数据），请改变国家，
- 我需要选择满足要求的X类的实例（来自DB的一个）。想想
从{class x}中选择 * last_changed_date＆gt; 5天前; - 然后创建一个命令来更改X的这些实例的状态（在我的情况下，将更新静态命令DB，以及为更新读取db的事件
）是让我困惑的原因。如果我将数据从读取数据库中抽出，然后检查一些信息，然后决定更改属性；然后，我必须将对象从“读取对象”转换为“命令对象”，以便我可以坚持下去并创建事件？使用我当前的架构 - 我可以查询命令db没问题，以找到与标准匹配的所有实例，但是我不知道a）这是正确的选择，b）如果我将活动商店用作DB，这将有效吗？我必须查询一张数百万行的桌子，以找到有关对象的最新状态，然后看看它们是否匹配？
我在网上阅读的许多内容都是非常概念上的 - 所以我认为在实施方面，它似乎比以前更困难？无论如何，如果有人有任何建议，将会非常感谢！
tia :)
I'm currently looking at implementing CQRS driven by events (not yet event sourcing) in for a service at work; the reasoning being:
- I need aggregate data to support a RestAPI coming out of this service (which will be used to populate views)- however the aggregated data will not be used by the application logic/processing (ie the data originating outside this service, the bits that of the aggregate originating within it will be used)
- I need to stream events to other systems so that they can react to the data (will produce to a Kafka topic, so the 'read'/'projection' side of this system will consume the same events as the external systems, from these Kafka topics
- I will be consuming events from internal systems to help populate the aggregate for the views in first point (ie it's data from this service and other's)
The reason for not going event sourced currently is that a) we're in a bit of a time crunch, and b) due to still learning about it. Having said which, it is something that we are looking to do in the future- though currently, we have a static DB in the 'Command' side of the system, which will just store current state
I'm pretty confident with the concept of using the aggregate data to provide the Rest API; however my confusion is coming from when I want to change a resource from within the system (for example via a cron job triggered 5 times a day) Example:
- If I have resource of class x, which (given some data), wants a piece of state changing
- I need to select instances of the class x which meet the requirements (from one of the DB's). Think
select * from {class x} where last_changed_ date > 5 days ago; - Then create a command to change the state of these instances of x (in my case, the static command DB would be updated, as well as an event made to update the read DB)
The middle bullet point is what is confusing me. If I pull the data out of the Read DB, and check some information on it, then decide to change a property; I then have to convert the object from the 'Read Object' to the 'Command Object', so that I can then persist it and create an event? With my current architecture- I could query the command DB no problem, to find all the instances of {class x} that match the criteria, however I don't know if a) this is the right thing to do, and b) how this would work if I was using an event store as a DB? I'd have to query a table with millions of rows to find the most recent bit of state about the objects, to then see if they match?
Lots of what I read online has been very conceptual- so I think when it comes to implementations it maybe seems more difficult than it is? Anyhow, if anyone has any advice it would be hugely appreciated!
TIA :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
CQR可以以“宽容”的方式解释：它不说“您不追究命令/写入侧”，而是说“可以有一个与命令/写入侧分开的查询/读取侧”。因为您有这样的允许进行这种分离的权限，因此可以以下是一个人可以优化命令/写入方面以进行更重写的工作负载（实际上，命令/写作方面总是有一些读取：因为通常完成了命令验证在某些状态下，这需要某种方法来获得国家！）。由此，很有可能会有一些查询可以在命令/写作方面有效地执行，而某些疑问不可能（而不必消除命令/写入侧）。从这个角度来看，可以对命令/写作方面执行第一种查询：您可以通过这样做可以从强大的一致性中获得好处 raison d'Etre 的写作。
事件采购在许多方面都是命令/写入方的最大优化持久性模型，尤其是如果您有一些方法可以保持绝对最新状态的缓存并确保并发控制。这是因为然后，您的写作要比阅读多倍。事件采购中的权衡是，几乎所有读取都比就地更新模型更昂贵：因此，通常情况下，CQR不强迫事件采购，但是事件采购倾向于迫使CQRS（反过来，而事件，事件采购可以简化确保CQRS系统最终是一致的，这可能很难确保实地更新）。
在事件采购的系统中，您倾向于具有读取事件流的读取端，并将
x ID的映射跟踪到上次更新以及哪些定期查询和问题命令。另外，您可以拥有一个调度程序服务，让您可以说“此时发出此命令，除非在此之前取消或重新安排”，并且可以订阅更新并为给定ID的命令订阅，从现在起5天后，从上一个更新中的命令。CQRS can be interpreted in a "permissive" way: rather than saying "thou shalt not query the command/write side", it says "it's OK to have a query/read side that's separate from the command/write side". Because you have this permission to do such separation, it follows that one can optimize the command/write side for a more write-heavy workload (in practice, there are always some reads in the command/write side: since command validation is typically done against some state, that requires some means of getting the state!). From this, it's extremely likely that there will be some queries which can be performed efficiently against the command/write side and some that can't be (without deoptimizing the command/write side). From this perspective, it's OK to perform the first kind of query against the command/write side: you can get the benefit of strong consistency by doing that, though be sure to make sure that you're not affecting the command/write side's primary raison d'etre of taking writes.
Event sourcing is in many ways the maximally optimized persistence model for a command/write side, especially if you have some means of keeping the absolute latest state cached and ensuring concurrency control. This is because you can then have many times more writes than reads. The tradeoff in event sourcing is that nearly all reads become rather more expensive than in an update-in-place model: it's thus generally the case that CQRS doesn't force event sourcing but event sourcing tends to force CQRS (and in turn, event sourcing can simplify ensuring that a CQRS system is eventually consistent, which can be difficult to ensure with update-in-place).
In an event-sourced system, you would tend to have a read-side which subscribes to the event stream and tracks the mapping of
X IDtolast updatedand which periodically queries and issues commands. Alternatively, you can have a scheduler service that lets you say "issue this command at this time, unless canceled or rescheduled before then" and a read-side which subscribes to updates and schedules a command for the given ID 5 days from now after canceling the command from the previous update.