CQRS+Event Sourcing as Top Level Architecture: Anti-Pattern

by Entith   Last Updated July 09, 2018 21:05 PM

I have been study DDD along with CQRS and Event Sourcing. I recently listened to a talk Greg Young gave a couple years ago where he said that CQRS and Event Sourcing are not a top level architecture and should be used within the confines of specific bounded contexts. Doing otherwise would be an anti-pattern.

This makes a lot of sense in general, however it seems to conflict with what I perceived to be one of the benefits of an event sourced system: being able to have different context-specific aggregate roots of the same "thing" in different contexts, each reconstructed from the same event stream.

For example a Customer would have different implementation in different contexts (Ordering, Marketing/Product Recommendations, Customer Service, Authentication), however certain events would be relevant across multiple contexts (eg. CustomerEmailChanged would be relevant to Marketing, Customer Service, and Authentication. OrderPlaced would be relevant to Ordering and Marketing).

Prior to listening to that talk, my plan was to have these different contexts share an event store and just ignore events that were not relevant. And that stills seems like a very reasonable way to handle that, but I also can kind of see how this could be an anti-pattern, blurring the lines between various bounded contexts.

What would be the correct way to go about this, or is my approach altogether flawed?

Related Questions

How to create new aggregate root in CQRS?

Updated February 21, 2017 13:05 PM

CQRS - Passing aggregate root as argument

Updated February 25, 2017 23:05 PM

Sharing data between bounded contexts

Updated May 01, 2015 21:02 PM