Problem: Do We Need DDD Strategic Patterns When Doing EventSourcing ?

[ylorph]

No description provided.

[MerrionComputing]

I guess this rather depends on the question Is Event Sourcing an architecture ?

I would argue that it isn't (so it doesn't need DDD strategic patterns) but also add that Event Sourcing should be used inside an architecture (ideally CQRS) which does need DDD strategic patterns.

[skleanthous]

While I would argue that you don't need to apply DDD strategic patterns when doing event sourcing, strategic patterns reduce the risks significantly enough to be highly advisable to adopt them if doing event sourcing. This is due tp two aspects, the Ubiquitous language, and Bounded Contexts.

By discovering and definiting the ubiquitous language we discover the events which are inherent in our domain, which (by definition if they are part of the language) are at least recognised, if not already used in one way or another, by our domain experts. This helps us come up with events which are less likely to have breaking changes, and more likely to have incremental changes as we add features to our system.

The discovery of bounded contexts also reduces risk even further, because it makes clear that two same-named -and probably semantically similar- entities, have in fact significant differences, which guide us towards more fine-grained event streams and events, which increases maintainability and reduces the risk of large refactors down the line.

I am not certain about this, but if Event Storming (and similar modelling workshops) falls under the general umbrella of DDD strategic patterns, then this would also be another significant reason to adopt the stragegic paterns when also doing event sourcing.

[johnbywater]

@skleanthous Well said. That's pretty much the way they figure in my book Event Sourced Building Blocks for DDD with Python. But I didn't include any such well explained justification as you put it just there ;-)

https://leanpub.com/dddwithpython