Shared read model across several bounded contexts

[Charles Desneuf]

Hi all !

I have read in a few places (Martin Fowler on CQRS, Udi Dahan's Clarified CQRS article) that CQRS should be applied within a bounded context.

To my understanding it means that creating a read model with information coming from several contexts is a bad idea.

Am I wrong in my interpretation of this statement ?

I don't see what are the potential drawbacks of creating a composed read model and I can think of some use cases where having one might be a huge benefit.

For instance when delivering an API we might want to display resources with data coming from several contexts. A composed read model will increase performance and help with potential search and filter features.

Thanks in advance for your feedback

Charles

[Kijana Woodard]

I don't know about "read model" [singular], but the entire value proposition for most apps is expressed by combining data from multiple contexts. The questions are when, where, and how.

Traditional approaches do it implicitly and haphazardly. [Oh, just query *the* db]

Be explicit.

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

[Charles Desneuf]

Thanks Kijana for taking the time to answer me.

Is it a good idea to have read models in a storage mechanism which are created and modified listening to event coming from several bounded contexts ?

Something like a "super query side" of the application using it's own storage.

This seems to me to be going against the advice of applying CQRS in a context because we are using it in a broader system but I don't see why this is a terrible idea.

I'm not convinced this is way clearer than the first time...

[Greg Young]

There is nothing wrong with combining ... 

Some say you should do everything as composed in the ui. The shared read model can just be a persistent view model. Some trade offs between but both are fine.

Greg

--

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.

--

Studying for the Turing test

[Chris Sampson]

If you have many contexts, one way of doing it is to keep read models for each context with that context and then use some from of UI composition to combine it all. I believe that Amazon uses this approach.

As each context is then responsible for the writing and querying of its own set of data, it makes it a single unit, affording it to be have any flavour of model ( > Crud, CQRS, Trad DDD etc) without affecting anything outside of it - Other than sending  "data-less" events to inform other contexts of happenings. I.e. the ownership of data is not leaked to other contexts

--

[Charles Desneuf]

Thanks all for your quick answers.

I guess I'll try to test both approaches to see what feet the best in the project.

Le vendredi 12 juin 2015 16:09:33 UTC+2, Charles Desneuf a écrit :

[Ben Kloosterman]

Udi in most of those articles is talking about SOA as the overriding architecture and in that environment smaller  broken down data-sets have significant benefits.  eg how easy is to replace or overhaul the SOA ContactDetailService . Remember this is not just 1 business system but many .  

His articles especially ask what is the top level arch because CQRS is not a top level arch. If you have a large composite DB your top level arch is obviously 2.5 Tier or 3 Tier which may or not be appropriate.  It typically depends on the amount of integration you need. 

Regards,

Ben