When some BCs are not event-sourced then how to communicate?

[Dariusz Lenartowicz]

Greg Young — A Decade of DDD, CQRS, Event Sourcing

https://www.youtube.com/watch?v=LDW0QWie21s

I've watched Greg's presentation again. Greg says that We should not build event-sourced systems and there should be only a few places where it should be used.

So. If I have a couple of BCs and not all of them are event-sourced and I want to communicate them then should I use some additional message bus (another complexity)?


Regards
Darek

[Rupesh Kumar Tiwari]

Even I read in Udi Dahan blog they were saying CQRS is also not needed everywhere. 

http://udidahan.com/2012/02/10/udi-greg-reach-cqrs-agreement/

If it certain BC is collaborative or competitive then only we do CQRS. Also in CQRS it is not always need to do big CQRS where use event sourcing etc. It is very special cases where we do full blown CQRS with event sourcing. Also in order to communicate among BC's I would recommend using messaging with Service Bus framework ( masstransit or nservice bus )

Thanks,

Rupesh kumar Tiwari

 

--
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+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Dariusz Lenartowicz]

Service Bus framework ( masstransit or nservice bus )... Right. It means to lose all those data sent through message-bus (instead of saving it in eventstore)?

W dniu piątek, 12 maja 2017 19:51:37 UTC+2 użytkownik Rupesh Kumar Tiwari napisał:

Even I read in Udi Dahan blog they were saying CQRS is also not needed everywhere. 

http://udidahan.com/2012/02/10/udi-greg-reach-cqrs-agreement/

If it certain BC is collaborative or competitive then only we do CQRS. Also in CQRS it is not always need to do big CQRS where use event sourcing etc. It is very special cases where we do full blown CQRS with event sourcing. Also in order to communicate among BC's I would recommend using messaging with Service Bus framework ( masstransit or nservice bus )

Thanks,

Rupesh kumar Tiwari

 

On Fri, May 12, 2017 at 1:43 PM, Dariusz Lenartowicz <dariusz.l...@gmail.com> wrote:

Greg Young — A Decade of DDD, CQRS, Event Sourcing

https://www.youtube.com/watch?v=LDW0QWie21s

I've watched Greg's presentation again. Greg says that We should not build event-sourced systems and there should be only a few places where it should be used.

So. If I have a couple of BCs and not all of them are event-sourced and I want to communicate them then should I use some additional message bus (another complexity)?


Regards
Darek

--
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.

[Rupesh Kumar Tiwari]

Sorry may be I could not explain myself better. 

I may be wrong but what I think is:

If we are doing CQRS with event sourcing within a service boundary then yes we will use event sourcing technique. 

And there are some other services/BC where we do not want to do CQRS with event sourcing. So there we will just use in memory publish or service bus message publishing mechanism to update Query model and Command model can be just an entity saved in DB you may not need any event sourcing here. 

I believe CQRS can be done with event sourcing and without event sourcing also. It is a style of pattern so it is not useful everywhere. Udi Dahan has notion of big / small CQRS where he says small CQRS where we don't need event sourcing and query db also. 

Even Martin Fowler says:

"In particular CQRS should only be used on specific portions of a system (a BoundedContext in DDD lingo) and not the system as a whole. In this way of thinking, each Bounded Context needs its own decisions on how it should be modeled."

https://martinfowler.com/bliki/CQRS.html

Now if we want to communicate among these services then we can use service bus frameworks with messaging.

Thanks,

Rupesh kumar Tiwari

 

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

[Juan]

Hello. From my point of view, cqrs or cqrs+es, or no cqrs at all, is the internal architecture of the BC.

The rest of the world shouldnt bother about what architecture the BC uses.

To integrate with it you could provide an OHS with a PL. For example a rest api.

[Yves Lorphelin]

You need to integrate.... there are existing techniques and patterns . As well as technologies.
It all boils down to the needs of your specific systems.
What are those ?then choose the best for the purpose

[Riccardo Di Nuzzo]

To decide if a BC need to be EventSourced I check if there is a requirement to keep track of changes across the time. This is a common requirement for relevant business features modeled as Bounded Contexts so it is not rare that the important BC's are internally Event Sourced. 

How the components integrate between each other is not related to the internal patterns used to store results.

The integration can be done using a Pub/Sub pattern. I prefere it instead Request Response for resiliancy. 

In the past I mixed service bus libraries with Event Store and it was not a good mix. It could works but it can be difficult to learn, deploy, monitor and maintain. For that reason I usually use only Event Store. Each BC read from an input stream the commands. Each BC publish to an output stream external events. No need for other libraries. 

If the external events become to many and especially between some BC's then the question is about the need to re-shape the BC's to avoid that. Different topic is about the ReadModel synchronisers as they are outside the domain and are used for the needs of reporting.

On the CQRS topic.

In my opinion the main benefit of CQRS is to (re)build a read model at any time replaying the events from or to a certain point in time. You need a central ordered log for that. Without it you need just a bit of a luck and work with database replication or some sort of cache mechanism.

Cheers 

Riccardo

[Kijana Woodard]

Consider a BC owned and operated by another company on another network. How would you communicate?

You can quickly see the your choice of event sourcing makes no difference ad to your ability to communicate.

Fwiw, that thought experiment also exposes flaws in integrating across contexts via a database. 

If the BCs are autonomous, they should be able to have whatever implementation and technicalities make sense for their problem.

--

[Ben Kloosterman]

Re how to communicate .

How have SOA and REST services been communicating for 15 years or so ?

I like short duration requests to go direct to a Web api CRUD service and throw errors back to the caller removes a lot of complexity  for most cases.  Fire and forget brings in a lot of issues when it is expected to be fulfilled and cant be . Its easy enough to call CQRS via a web API .

There will be cases where you need pub / sub and some event processors reading from a bus but this is probably a small portion.  

"I believe CQRS can be done with event sourcing and without event sourcing also. It is a style of pattern so it is not useful everywhere. Udi Dahan has notion of big / small CQRS where he says small CQRS where we don't need event sourcing and query db also. "

Disagree , I thought so and read that material so i tried this for one project and the results were poor.  I think if you have ES you go CQRS, CQRS without ES  is a enhanced form of DDD and like DDD has a lot of infrastructure complexity ( but more). There can be cases where you do this but you would need to see a very high user / transaction count. 

"Hello. From my point of view, cqrs or cqrs+es, or no cqrs at all, is the internal architecture of the BC.

The rest of the world shouldn't bother about what architecture the BC uses."

Agree. So why are people running to complicated EDAs/ ESB's for everything ?  I try to avoid them and just use a pub sub server for the few cases where it is needed. 

The most thing as Kijana alluded to is that BCs should be independently deploy-able and hence have its own data. 

Note there are some suggestions for very large clusters with fine grained micro services that you want to do a lot more event sourcing ( due to its distributed nature and requests spanning services)  but im not convinced the extra cost of doing this for most services is worth it yet .

Regards,

Ben