EventStore without CQRS

I learned a lot about EventStores, but all of the articles are about talking about CQRS.

We want to use EventStores to integrate limited contexts, but we want to stick to the traditional ORM for reading / writing aggregates to avoid a command / query and a separate reading model, which in our case will be too complicated.

Seeing that it is so popular to talk about all the concepts together, we can assume that they are designed for living together - are there any drawbacks in creating an EventStore "lite" without CQRS, compared to implementing EventStores for aggregates / CQRS / read - is the model also?

+7
source share
2 answers

Run in NoSql Distilled - you will save a lot of time by not doing anything for several days, but by reading it and drawing what you are after. If you read / write aggregates, you should consider databases such as RavenDB, which are important in this.

Note that the event store tag is for the JOliver event store, and it has key architectural concepts

You also have things back a bit to get to creating events; your domain is created specifically to facilitate this. The main things that contrast with the way you position things in your question (to rephrase badly and / or unfairly: I want to use the event store only to store events - I can do the rest myself)

  • events are grouped together - its real event management unit

  • sending something.

Go on to consider queuing solutions if you do not want a domain model to be obtained. This is a very legitimate thing - just don't pretend the Event Store is a generalized sub pub queue.

Having a Dispatcher project for the Denormalizers that create the Read Model is a simple bit - you can use all sorts of exotic things, but using a familiar tool like SQL SB with a simple database layer like PetaPoco would be fine.

Have you really made a splash with CommonDomain and EventStore? Have you read readme doc in nuget? Have you watched 2 JOliver videos?

+4
source

We want to use EventStores to integrate limited contexts.

You can use the event store as a message queue with the added advantage that it is permanent, and a new subscriber can request all past events.

but you want to stick to traditional ORMs for reading / writing aggregates to avoid a command / query and a separate reading model, which in our case will add too much complexity.

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

In general, you can use EventStore without using an event source , however you must make sure that it supports all the requirements of your integration script. You may need other components in addition to the event repository. More generally, the event store can be used to store any time series data.

+1
source

All Articles