Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

CQRS + Event Sourcing without DDD

I'm building a system thats very data centric. I have large hierarchical datasets but no business rules. The output of the system comes from some calculations done on the data and a number of reports. I need to have a complete audit trail (for regulatory reasons) and be able to run the calculations against a dataset from any point in it's past.

For these reasons I thought having an event sourced system using CQRS was the way to go. All the examples I've seen revolve around creating aggregates to do ES. The problem I have is because each piece of data is one large related set I'd have a small number of massive aggregates. The alternative seemed to be splitting the set up into it's parts and calling each one an aggregate. But, in order to do any calculation I would have to load hundreds of thousands of aggregates.

My question is, does anyone have experience of CQRS + ES systems that are data centric and what that might look like?

Is there a better way to store the history of a dataset without using ES?

Thanks for any help.

like image 276
Colin Avatar asked Mar 19 '15 11:03

Colin


People also ask

Can we use the CQRS without the Event Sourcing?

With Event Sourcing this is possible. Without ES it's not possible because you only store the final state of the cart.

Is CQRS part of DDD?

The short answer is: Yes, you can. CQRS as an architectural style came after DDD. It's based on the Command-Query Separation (CQS). As a pattern CQRS can be used to optimize your application.

What benefits do we get when we use Event Sourcing with CQRS?

Event sourcing is a powerful pattern and brings a lot of benefits to an application architecture if used appropriately: Makes write operations much faster as there is no read, update, and write required; write is merely appending an event to a log.

What is CQRS Event Sourcing?

In a CQRS context, one benefit of Event Sourcing is that the same events can be used to notify other components — in particular, to notify the read model. The read model uses the events to create a snapshot of the current state, which is more efficient for queries. However, Event Sourcing adds complexity to the design.


1 Answers

But, in order to do any calculation I would have to load hundreds of thousands of aggregates.

Language check: aggregates only exist in the write model (C). Calculations and reports come out of the read model (Q). You aren't, after all, changing/appending to the event history when you report on it.

It's an asset management system. Each Asset has 100k+ pieces of equipment.

That sounds a bit like an inventory tracking system. Greg Young has remarked that "in most inventory systems there are no commands."

Because the "book of record" is the real world, not the model, "commands" don't make sense -- the model isn't allowed to reject reality. Without commands, aggregates go away; there are no business rules to enforce. Just events that announce changes to the real world.

The basic pattern of CQRS+ES still works, which is to say that you write a history of events into your persistence layer (that's your audit trail), and publish events out of this record, so that your other projections can update.

You'll need to consider how many event streams are appropriate for your situation. In CQRS solutions where the domain model is the book of record, each aggregate normally writes to an exclusive event history (reducing contention); models that need data from more than one stream join them together. So you might want to do something analogous for your different external event sources. Alternatively, you might have them all publish into a single event stream, and then have the read models filter out the events that they don't need.

like image 193
VoiceOfUnreason Avatar answered Oct 10 '22 16:10

VoiceOfUnreason