Add BoundedContext abstraction

[carlos-verdes]

A single cqrs framework should be able to manage more than one aggregate.

Related with #90

[davegarred]

That's certainly not the design here.

This is probably more of a naming problem since 'framework' implies you might handle multiple aggregates.

[carlos-verdes]

Correct me if I'm wrong but let's say I need to implement a Query that read events from 2 different aggregates, from the documentation the simplest Query example looks like this:

struct SimpleLoggingQuery {}

#[async_trait]
impl Query<BankAccount> for SimpleLoggingQuery {
    async fn dispatch(&self, aggregate_id: &str, events: &[EventEnvelope<BankAccount>]) {
        for event in events {
            println!("{}-{}\n{:#?}", aggregate_id, event.sequence, &event.payload);
        }
    }
}

On this example (and others looks similar) I have to provide one aggregate type only, hence I can't handle events from other one.

One option is to create an enum with all aggregates the query is interested in + implement From trait like this:

enum BankQueryInput {
  case BankAccount(BankAccount),
  case TaxesAggregate(TaxesAggregate),
}

impl From<BankAccount> for BankQueryInput {
  ...
}

This way I could write a Query which is interested on bank account movements and tax events. Let me know if this example has sense to you.

[davegarred]

With two aggregates you'll need two different Query implementations, but these can absolutely work on the same backing store.

[carlos-verdes]

How it can work if 1 store is linked to 1 aggregate? It simply can't right?

[davegarred]

struct BankAccountAggregate;
struct CustomerAggregate;

struct MySharedQuery {}

impl Query<BankAccountAggregate> for MySharedQuery {
   ...
}

impl Query<CustomerAggregate> for MySharedQuery {
   ...
}

[carlos-verdes]

So you will have 2 instances of the same query working in parallel, like creating 2 listeners, 1 per aggregate, then both will write the state on the same table or collection right?

I was thinking on a more simple scenario where the query receives interleaved events from both aggregates, but this approach has sense too as we can't enforce that both aggregates live on the same infrastructure.

[davegarred]

That is not supported, in CQRS terms order of events only makes sense within a single aggregate.

[carlos-verdes]

I still have doubts your example would work with a real example but I'll have a look into it. I created my own library (replay) based on this library but with a different approach.