Shared event store between bounded contexts?

[Alex Sanchez]

Can't find any info on this, so I guess I'm missing something fundamental:

Suppose I'm developing three BC with CQRS and Event Sourcing.

Can I (and should I) use one event store shared by all three BC, or should each BC have it's own event store?

What's best practice here? How do you guys do it?

Thanks

/Alex Sanchez

  

[Kasey Speakman]

I would think you will want separate ES instances unless your event store supports multiple tenants (or multiple databases if your ES is backed by a separate database). Your denormalizers probably only want to handle events from one BC, not all of them. Also consider what happens when multiple BCs use the same name for an aggregate type and one BC wants to regression test only theirs. Greg's example of an insurance "policy" comes to mind where sales and claims BCs view policies very differently.

https://www.youtube.com/watch?v=KXqrBySgX-s
First 30 mins about BC modeling with insurance policy example.

[Mirko Bonadei]

Hi Alex, is there a necessity to make it shared?

For example to integrate events from the 3 BCs?

This is interesting because I am in a similar situation.

Mirko

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

--
Mirko Bonadei
Grassobbio (BG) Italia
http://www.mirkobonadei.com

http://www.erlangthoughts.com

My Twitter

About.me

[João Bragança]

My experience has been that at least some of your read models for views will combine events from multiple BCs. In that case just use a different naming prefix in the same event store.

policy-123

origination-123

Sent from my regular computer

http://twitter.com/thefringeninja

http://www.thefringeninja.com/

[Mirko Bonadei]

Same experience as mine.

123 does't seem the aggregate id in this case. Is it the conversation id?

I am trying to use EventStore for this.

Mirko

Sent from iPhone

[Alex Sanchez]

Thanks guys, I've only done CQRS within one BC.

Mirko, I have no requirements to have a shared event store but thought it could be convenient.

Sounds like a good idea though to have a separate event store. I'm thinking about the case when two bounded context have an aggregate type with same name.

[Greg Young]

Multiple bcs can be seen as multiple tenants. There are many ways of handling multiple tenants. A big question would be if you want multiple tenant querying

--

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.

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Mirko Bonadei]

Hi Greg, suppose that we want to support multi tenant queries. Which is the way you suggest?

Sent from iPhone

[Greg Young]

If you want to query across tenants then putting them together makes sense. Consider it the equivalent of putting a "tenant id" on a table.

[Mirko Bonadei]

I have put a source field in each Event to know which is the BC that owns the Event. Is it this?

Mirko

[João Bragança]

sales-policy-123

claims-policy-123

Assuming your eventstore supports strings for stream names :)

[James Nugent]

If you’re using the Event Store and using projections bear in mind what fromCategory will do - you might want to switch to categorising based on the last “-" rather than the first.