Nice article, Ralf! I really like the idea of scopes. They rely on facts already present, i.e. prior events. This is exactly the opposite of tags in DCB, where you need to think about the possible contexts in which a given event might be relevant. In my view, tags introduce structural thinking via a backdoor. Scopes strengthen the behavioral view.
Ralf, in a task management application, or banking, many slices would be interested in the current task status, or the current account balance. Would each slice have its own event store query? Queries may be very intricate, and once implemented, developers working on new slices will copy or re-use existing queries.
Or could the event store itself have a list of pre-defined queries, like views or stored procedures in a database?
The beauty of an AQ architecture is: you can share contexts, context models as much or as little as you want. No pressure!
Create your context model 1 for slice 1 as you like.
Create your context model 2 for slice 2 as you like.
...
If you realize while implementing slice 12 that its context model looks like that of 4 and 7, consider extracting it. Congratulations you discovered a pattern.
Once a pattern is discovered sharing code for it is ok (as long as you understand the responsibilities coming with the reuse you're aiming for).
This is very different from CRUD architectures which require you to think ahead and create a single, central model already fit for all kinds of unknown purposes.
Each slice has a context. Each context can serve multiple slices. Maybe slices are sharing just the context (aka the result of an event store query) or a context model as a data structure or a full blown object graph as a context model... that's up to you.
Just be sure to understand the dangers coming along with sharing.
Nice article, Ralf! I really like the idea of scopes. They rely on facts already present, i.e. prior events. This is exactly the opposite of tags in DCB, where you need to think about the possible contexts in which a given event might be relevant. In my view, tags introduce structural thinking via a backdoor. Scopes strengthen the behavioral view.
I am glad you're sharing my view!🥳
Ralf, in a task management application, or banking, many slices would be interested in the current task status, or the current account balance. Would each slice have its own event store query? Queries may be very intricate, and once implemented, developers working on new slices will copy or re-use existing queries.
Or could the event store itself have a list of pre-defined queries, like views or stored procedures in a database?
The beauty of an AQ architecture is: you can share contexts, context models as much or as little as you want. No pressure!
Create your context model 1 for slice 1 as you like.
Create your context model 2 for slice 2 as you like.
...
If you realize while implementing slice 12 that its context model looks like that of 4 and 7, consider extracting it. Congratulations you discovered a pattern.
Once a pattern is discovered sharing code for it is ok (as long as you understand the responsibilities coming with the reuse you're aiming for).
This is very different from CRUD architectures which require you to think ahead and create a single, central model already fit for all kinds of unknown purposes.
Each slice has a context. Each context can serve multiple slices. Maybe slices are sharing just the context (aka the result of an event store query) or a context model as a data structure or a full blown object graph as a context model... that's up to you.
Just be sure to understand the dangers coming along with sharing.