Distributed application using RabbitMQ

Question

I am on my way to create an application with 4 bounded context using CQRS & event sourcing.

In order to make these bounded context talk to each other I was planning on using Rabbit MQ.

My requisites are the following :

• The bounded context must not know about each other
• The bounded context must not be hindered if the other bounded context are down or if rabbitMQ is down
• If a bounded context is not available the messages, that it should receive, must wait patiently for its return ie : every event published must be forwarded at least once to all the bc interested.

Therefore, I was thinking about having each of them referencing a queue : BandMasterQueue and creates it if it is not.

When producing an event, the event store stores it and its dispatch consists of two steps :

1. project on itself this event to every little projection. Each projection has a little tiny store of events already projected to warrant idempotency over some period of time.
2. publish this event to the queue BandMasterQueue

if it would fail on step 2 because of no rabbitmq available, then I expect my event store to try again to dispatch the message to the RabbitMQ after sometime (not really though precisely about this part, I must say...)

The bandMaster "bounded context" knows about every different BCs he looks after. He is the one reading the bandMasterQueue and decides which events are public and which are not. He is also responsible to handle the "sagas" and can send corrective actions to each bc.

In order to do that, he will comunicate with each bounded context using the dedicated queue of the bounded context and creates it if it does not exits.

Each BC is bound to this specific queue, and add the event coming from outside in its own event store, and afterwards project it to its own projection.

Should this "architecture" work or do you see any major flaw in it?