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 :
- 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.
- 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?
1
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.
2
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.