Splitting up bounded contexts with Eventsourcing

Domain-Driven Design
1

We decided to extract out a new bounded context from a large existing one. Our events have this format:
<Context>::<Aggregate><Event>, an example could be: Shipping::CustomerAddressChanged.
Our stream names look like this: <Context>::<Aggregate>$<aggregate-id>.

So now, if we extract the example event to a new bounded context, we will end up with a new stream and new event names. Let’s say we name the new context “Delivery” (random, made up example).
This would change our event to Delivery::CustomerAddressChanged and the customer aggregate stream to Delivery::Customer$<aggregate-id>. This will obviously break building aggregate states, as we now need to consider the old and the new stream whenever we apply events.

We discussed this in the team today and came up with a good solution we think:

We can stop publishing to the first stream, create the new stream and publish a summary or snapshot event in there with our complete aggregate state. Now we change our consumers to be able to handle the snapshot event and switch them to listen to the new stream and all is good.

Does this make sense? Any problems with this solution? Any better ideas?

2

How many events are there? For your case, I’d prefer to migrate events from old streams to new streams or even to a completely new store. It would also allow you to clean up the data and, potentially, remove the data you don’t need anymore.

3

About 20k streams with something like 10-100 events each. We do need to keep the old events though. Is migrating events to a new stream straight forward? How would we do this with eventstore? Keeping the old stream would preserve history in a way that we’d also see in which context the events previously were. However, that might not be relevant actually.

4

Migration is as simple (or complex) as read a stream and write events to a new stream. Your volumes are quite small, so I don’t see an issue there. It will take just a few minutes.