EventStore without CQRS
Asked Answered
V

2

8

I have seen a lot about EventStores but all articles are coupled with talk about CQRS.

We want to use EventStores to integrate bounded contexts, but want to stick with traditional ORM for reading/writing aggregates, to avoid the command/query and separate read-model which in our case would add too much complexity.

Seeing as it is so popular talking about both concepts together one is led to believe they are meant to live together - are there pitfalls of doing an EventStore 'lite' without CQRS, compared to implementing EventStores for aggregates/CQRS/read-model also?

Vish answered 27/3, 2013 at 9:4 Comment(1)
In order to use the event store approach, you sorta need to have a system where all data-changing operations are caused by a command and result in an event (that you can then store and replay). This is quite a natural fit in a CQRS environment - but I don't see any reason why you couldn't create such a system yourself, too - it just takes discipline to handle all data changes through commands and fire events to report on what's happened.Urease
I
4

Run to NoSql Distilled - you'll save a lot of time by doing nothing for a few days but reading it and drawing out what you're after. If you are 'reading/writing aggregates' you should be considering databases such as RavenDB that major in that.

Note that the event-store tag is for the JOliver Event Store, and it has as key architectural notions

You also have things slightly backwards in that to get to producing events, your domain gets built in a particular manner to facilitate that. Key things that contrast with the way you posit things in your question (to paraphrase badly and/or unfairly: I want to use event store just to store events - I can do the rest myself)

  1. events are batched by aggregate - its real unit of management of events

  2. dispatching to something.

Go investigate queue management solutions if you don't want an event sourced domain model. This is a very legitimate thing to do - just dont pretend Event Store is a generalised event pub sub queue.

Having the Dispatcher Project to Denormalizers that build a Read Model is the easy bit - you can use all sorts of exotic stuff but using a familiar tool like a SQL SB with a straightforward database layer like PetaPoco will do fine.

Have you actually done a spike with CommonDomain and EventStore ? Have you read the readme doc in the nuget? Have you watched the 2 JOliver videos?

Indolent answered 27/3, 2013 at 21:49 Comment(3)
Ruben thanks for the valued reply, I found one video vimeo.com/31153808 can you please link me to other (you mentioned there were 2) - cannot find the other!Vish
@g18c edited in. IIRC the one you found is the best single one but the others are def worth a viewIndolent
Thanks for those links - yes the video is great and really helped my understanding. Since joliver has written the code in such a methodical way it will not be much overhead to implement commands and handlers as it will probably save me much time in ORM mapping. I knocked up a quick demo (having one slight issue with it) #15724140 but so far very impressed with this libraryVish
D
1

We want to use EventStores to integrate bounded contexts

It is possible to use an event store as a message queue with the added benefit that it is persistent and a new subscriber can request all past events.

but want to stick with traditional ORM for reading/writing aggregates, to avoid the command/query and separate read-model which in our case would add too much complexity.

As an aside, you can still attain some of the benefits of CQRS by simply using a separate read-model for queries rather than your behavioral model.

Overall, you can use an EventStore without using event sourcing, however you should ensure that it supports all requirements of your integration scenario. It may be that you need other components in addition to an event store. More generally, an event store could be used to store any time series data.

Dottydoty answered 27/3, 2013 at 15:31 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.