没有事件来源的CQRS-有哪些缺点？ [英] CQRS without Event Sourcing - what are the drawbacks?

问题描述

除了缺少Event Sourcing的一些好处外，在没有Event Sourcing的情况下将现有体系结构适应CQRS还有其他缺点吗？

我在工作在大型应用程序上，开发人员应该能够在未来几个月内将现有体系结构分解为命令和查询，但是从资源的角度来看，要求他们在此阶段还添加事件源将是一个巨大的问题。我是否通过不包括事件源来进行祭祀活动？

解决方案

事件源是可选的，并且在大多数情况下，如果使事件复杂化，它会带来更多的帮助推出还为时过早。

尤其是当从传统体系结构过渡时，甚至在团队没有CQRS经验时，甚至更多。

大部分归因于ES的优势可以通过将事件存储在一个简单的事件日志。您不必放弃基于状态的持久性，（但从长远来看，您可能会这样做，因为在某些时候它将成为下一步的逻辑）。

我的建议：简洁是关键。一次执行一个步骤，尤其是在引入如此巨大的范式转换时。从简单的CQRS开始，然后在您（和您的团队）习惯新概念时引入事件日志。然后，如果需要，将您的持久性更改为事件源并解雇DBA;-）

Besides missing some of the benefits of Event Sourcing, are there any other drawbacks to adapting an existing architecture to CQRS without the Event Sourcing piece?

I'm working on large application and the developers should be able to handle separating the existing architecture into Commands and Queries over the next few months, but asking them to also add in the Event Sourcing at this stage would be a HUGE problem from a resourcing perspective. Am I committing sacrilege by not including Event Sourcing?

解决方案

Event Sourcing is optional and in most cases complicates things more than it helps if introduced too early. Especially when transitioning from a legacy architecture and even more when the team has no experience with CQRS.

Most of the advantages being attributed to ES can be obtained by storing your events in a simple Event Log. You don't have to drop your state-based persistence, (but in the long run you probably will, because at some point it will become the logical next step).

My recommendation: Simplicity is the key. Do one step at a time, especially when introducing such a dramatic paradigm shift. Start with simple CQRS, then introduce an Event Log when you (and your team) have become used to the new concepts. Then, if at all required, change your persistence to Event Sourcing and fire the DBA ;-)

这篇关于没有事件来源的CQRS-有哪些缺点？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！