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?


2 Answers 2


Have a look at ZeroMQs documentation, especially the guide. I think you'd want something along the lines of their Figure 19 - Extended Request-reply. if not, there's a LOT of documentation there that should give you what you need in some combination.

I'm not sure what you mean in point 3, but the rest looks like it needs a disconnected message passing architecture - you fire messages at the network, and if a BC is up and listening, then it will receive the message to process.

If you need to send a message to a BC that is down, then you need a broker that reads them and waits for the BC to start whereupon it will send them to it - however, that means the broker needs to know about the BCs, in order to know whether to store messages for one.

  • Thx for your reply, I will definitely have a look at 0Mq. I had discarded it before because one of my requirement was to be able to send a message to a BC down. So that when it is up again, it takes back its pending messages.(that was my point 3, which was may be not so clear :) )
    – Arthis
    Jul 29, 2012 at 19:56
  • 1
    You can never send to a down server. What you can do is send to a message queue that waits for the downed BC to startup and connect to it to start receiving the stored messages. 0mq supports this with the ZMQ_QUEUE option - about zguide.zeromq.org/page:all#Built-in-Devices of the guide, or look at the Majordomo example. If not, go for amqp.org/about/what
    – gbjbaanb
    Aug 29, 2012 at 13:38

You might consider using a Queue Pooling mechanism in order to manage RabbitMQ Queues, and also to determine necessary pool-size under load. Here is a tutorial on the subject.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.