Does CQRS require an event bus...?

[Ashley Aitken]

Howdy All,

I am trying to learn and understand CQRS (and to use Akka Persistence to implement CQRS).

I would appreciate if you could help me by answering some general questions:

1. Does a CQRS implementation require some sort of event bus (or equivalent)?

I know CQRS can be implemented without event sourcing but it seems to me that any implementation requires a way for components to publish and subscribe to events on an event bus (at least to enable the decoupling of the read side but also for sagas etc).  

I am particularly thinking of Akka Persistence that currently has event sourcing but no integrated (not that it needs to be integrated) event bus.

2. If a CQRS implementation uses an event bus, does the event bus need to guarantee at least once delivery?

This would seem necessary to me because events not getting received due to some failure could cause problems, e.g. the read model getting out of sync and sagas missing key events, with no way to detect these failures or to recover.  

3. Is at least partial integration of the event bus and event store a useful thing to do?

It would seem that (at least partial) integration of the event bus with the event store would save on any duplication of event storage to enable at least once delivery in the event bus. For example, an event store that allowed components to publish and subscribe to events.

Akka Persistence provide a distribute journal of events for event sourcing which I suspect could be used to implement an event bus.

4. Is an event store required even if the implementation is not using event sourcing?

I am thinking without an event store it would not be possible to rebuild a read model or create a new read model.  Perhaps an event store is a part of the event bus (e.g. it has some sort of replay facility) but I am not sure about what an event bus can usually do or not do.

Sorry for all the questions and thanks in advance for any answers or comments.

Cheers,

Ashley.

[Ben Kloosterman]

CQRS systems don't need an event bus it comes from event sourcing and they can use a simple memory bus. 

I would start with simple CQRS , remember Martin Fowlers the first rule of distributed systems.. 

So take simple CQRS from https://github.com/gregoryyoung/m-r than put it on a DB you are familiar with . Focus on implementing the business rules not the infrastructure. 

My recommendation is if you are learning , is to use event sourcing as per simple CQRS its actually simpler.  When i was learning i started on thinking CQRS and non event sourcing  is simpler but i don't think so now. Eventsourced systems CAN become very complex but this should not be the case when you are starting ( or for most requirements) . Stick to simple things dont worry about more complex cases till your familiar with the simple 

Regards, 

Ben

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sebastian]

If you decide to go with "separating read and write models with explicit domain events and replacing the write model itself with those events", I have observed that beginners make a common mistake: thinking they need to go "bus" happy with endless permutations of complex asynchronous processing to handle really simple domains for which CQRS is not a good match. But I think experts give misleading advice, too, telling people to build their own frameworks because "you don't really need a framework". The advice is roughly right: the concepts are straightforward if handled properly. But in practice, a good event store with debugging support, good patterns already programmed, etc. is a non-trivial undertaking. Give geteventstore a try and understand how common patterns are implemented. Working with the simple in-memory model suggested above is definitely a good way to start warping your brain to understand the different pattern, but don't spend too much time trying to go to production building your own "not a framework".

Sebastian Good

[Ashley Aitken]

Thanks very much for the comments but can I please ask for some direct answers (if possible) to the questions:

1. Does a CQRS implementation require some sort of event bus (or equivalent)?

2. If a CQRS implementation uses an event bus, does the event bus need to guarantee at least once delivery?

3. Is at least partial integration of the event bus and event store a useful thing to do?

[Ashley Aitken]

My personal thoughts are:

1. Does a CQRS implementation require some sort of event bus (or equivalent)?

Yes. 

2. If a CQRS implementation uses an event bus, does the event bus need to guarantee at least once delivery?

Yes (to guarantee projections are correct) .

3. Is at least partial integration of the event bus and event store a useful thing to do?

Yes (it would seem useful).

 

4. Is an event store required even if the implementation is not using event sourcing?

Yes (for rebuilding/new) projections.

 

[Ben Kloosterman]

On Sat, Jul 5, 2014 at 11:45 AM, Ashley Aitken <amai...@gmail.com> wrote:

My personal thoughts are:

1. Does a CQRS implementation require some sort of event bus (or equivalent)?

Yes. 

No , this is a function of event sourcing not cqrs.

 

2. If a CQRS implementation uses an event bus, does the event bus need to guarantee at least once delivery?

Yes (to guarantee projections are correct) .

Not sure what you mean  by "guarantee at least once delivery" , generally an event source persists the event than fires it. That way if persistence fails the creator of the command that created the events can be notified  ( pref via synchronous call exception , else message) . Once it is saved if something goes wrong you can always rebuild the Aggregate from the events.

3. Is at least partial integration of the event bus and event store a useful thing to do?

Yes (it would seem useful).

The event bus is loaded from persistent storage so there is some integration .. 

 

4. Is an event store required even if the implementation is not using event sourcing?

Yes (for rebuilding/new) projections.

No.  Projections do not come from CQRS they come from event sourcing. Have a traditional single relational db have 1 service that does  all queries have another services that does all commands / BL .   You have a CQRS system .  

These are worth reading 

http://www.udidahan.com/2011/04/22/when-to-avoid-cqrs/

http://www.udidahan.com/2011/10/02/why-you-should-be-using-cqrs-almost-everywhere%E2%80%A6/

http://www.udidahan.com/2008/08/11/command-query-separation-and-soa/

Ben

[Michael Wightman]

CQRS is a logical  concept for service interactions not an implementation,  It requires no specific platforms or frameworks.  

The C in CQRS operations are logical  actions  like  [Terminate Employee ] [Change Employee Name] [Increase Salary] instead of just one [update Employee Record].  This pattern allows for higher concurrency rates  due to the fact that multiple unrelated operations can be performed on the same data without causing inconsistency.  The pattern also lends support for distributed processing without the need for distributed transactions via reversal command.  [Terminate Employee ] [Cancel Terminate Employee ] [Rehire Employee ] ]

The Q in CQRS defines a Logic Read Model tailored to be consumed by UI(logical UI) components not a specific implementation.  The logical read model can be simple db view(s) or persistent view(s)/projections that can be updated in the same procedure that process the command.  The UI should do a strait select without having to apply rules or collect extraneous data for display.

The use of an event store is a good implementation strategy for CQRS  but not required.

CQRS is not dependent on a BUS actually it is the other way around. The command in CQRS supports for the use of a service bus for distributed processing.  

If a bus does not deliver a command/message at least once what it the point.   At Least once delivery means support for the situation where the exact same command could show up multiple times and the command handler should be able to handle it gracefully. 

[Ashley Aitken]

Bennie and Michael, thank you very much for your thoughts in your posts.

I understand that CQRS is a logical concept and I was talking about implementations and I know that there can be many different implementations but I trying to get to the essence of what is required.  I also understand you could have a single data store with two services one for write and one for read and that would be CQRS but I believe the real benefits of CQRS come from having separate write and read models, particularly so the read models can be cached. 

I was suggesting CQRS requires some sort of event bus because there needs to be some sort of signalling between the write model and the read model when they are decoupled, and thus they need some sort of publish / subscribe for events.  I don't believe event bus is a function of event sourcing, at least in the sense that I understand event sourcing to mean the state of the domain is rebuilt from events rather than stored itself.  My definition could be too narrow here.

I think you could have an event bus without event sourcing.  And an event bus doesn't need to store the events although that would be necessary to guarantee delivery and for replaying the events (e.g. to rebuild a read model).  So "guarantee at least once delivery" was related to the read model subscribing to write model events.  If this subscriber wasn't guaranteed of receiving events (e.g. some were lost) then it's read model would become out-of-sync / corrupted.  

I guess to refine my question it would be whether communication of events between the write model and read model does require a bus (publish-subscribe) and whether this bus does require the ability to guarantee delivery of events (which as I mentioned would seem to imply some sort of persistence of events but not necessarily a full on event store).  

Thanks again for your posts they have helped me understand better.

Cheers,

Ashley.

[Christian Setzkorn]

I personally see no reason why events could not be generated without event sourcing. Could a crud-y anemic domain model not also generate events, which could then be used for denormalization? What does the community think?

[Kijana Woodard]

Sure. NServiceBus allows you to use events without event sourcing. CRUD could generate events just to invalidate cache....if you wanted.

@ashley.aitken - having an event bus is not required for two different 'models'. A model is a representation. CQRS doesn't require two services or two processes either. A bus might be useful if you have multiple processes and no event store. For *just* CQRS, you can have both models in one process accessing the same persistence engine.

You're segregating them as opposed to, say, using the same EF stack for both reads and writes.

---

From: Christian Setzkorn
Sent: ‎7/‎5/‎2014 10:56 AM
To: ddd...@googlegroups.com
Subject: Re: [DDD/CQRS] Re: Does CQRS require an event bus...?

[João Bragança]

+1. CQRS requires two different interfaces or object models, nothing more. The power comes from the freedom to re-implement those interfaces when the system requires it.

Sent from my regular computer

http://twitter.com/thefringeninja

http://www.thefringeninja.com/

[James Nugent]

> I personally see no reason why events could not be generated without event sourcing. Could a crud-y anemic domain model not also generate events, which could then be used for denormalization? What does the community think?

Is this not basically what the transaction log of an RDBMS is?

[Christian Setzkorn]

Is the transaction log denormalized ready to be consumed as a read model?

On 5 Jul 2014 21:54, "James Nugent" <ja...@geteventstore.com> wrote:

> I personally see no reason why events could not be generated without event sourcing. Could a crud-y anemic domain model not also generate events, which could then be used for denormalization? What does the community think?

Is this not basically what the transaction log of an RDBMS is?

[Greg Young]

What happens when your publish events and save and they dont align due to a bug etc??

Also you will most likely need 2pc

Studying for the Turing test

[Kijana Woodard]

"...if you wanted"

You probably don't, but I wanted to concentrate on the idea that all of these concerns are orthogonal to segregating commands and queries.

---

From: Greg Young
Sent: ‎7/‎5/‎2014 4:19 PM

[Ben Kloosterman]

Isn't that what DB views are ?

[Ben Kloosterman]

"...if you wanted"

You probably don't, but I wanted to concentrate on the idea that all of these concerns are orthogonal to segregating commands and queries.

+1.. you can run it of CRUD. 

And I suggest unless you are a DDD master that you look at something simple first  , the strength and the skills needed in CQRS is in designing and evolving business concepts not complex infrastructures which tend to distract from what you are really trying to do and without understanding how to implement these in CQRS you will probably build far more complex and unwieldy systems than need be. 

Once confident on the modelling which is not that easy to learn then  move onto more complex infrastructure. The strength of CQRS is  the business modelling and how clean it makes it .  Infrastructure and buses is not where your focus should be.