I am integrating different bounded contexts with Windows Service Bus and have some questions:
1) How to detected duplicates in other bounded contexts? Store the last processed message sequence? I want the ability to re-fire events to allow re-sync of new bounded contexts HandleEvent(OrderPlaced orderPlaced, bool isReplay) that are bought in to production in the future for an initial sync.
2) For the inter-context message bus, would we use a topic per bounded context (and have the namespace to group the bounded contexts)? Or a single bounded context per namespace?
3) The Message Bus documentation says messages can arrive out of order, what algorithm should be used to reassemble in order? What would happen if messages 6 and 8 were received, but 7 never came? Would we wait for a specified time, and then just continue? How to allow self repair?
4) I imagine the above is pretty common across almost all DDD projects, are there any libraries that handle the messaging including command/response protocol to request sync of previous events from a foreign bounded context?
This doesn't answer most of your questions, but gives you an alternative.
Lots of these problems went away when I started pulling events instead of having them pushed to me. If I'm pulling, I just keep a checkpoint of the event number I've processed up to. When I need to rebuild, I remove the read models and the checkpoint and the new read models will be created automatically. Since I'm using a single writer, duplicates are not an issue. Ordering isn't a problem either.
We still have events pushed out too though - but these are only used for reactive behavior. For example; when an order is placed, print a ticket.
Whether this makes sense to you, depends on how quick you need to react to things, and how fresh you need your data to be (1 second versus 30 seconds etc).