CQRS/ES - Way of Communication between two Bounded Context

Question

Hi I have a following scenario,

There is two seperate application

1. ShopManagament - This handle the registration of shop. Contaning aggregate Shop and other aggregates
2. NotifyService - This send the mail , sms , notification. Contaning aggregate Email , SMS , Nofication

The both application build using CQRS/ES with DDD.

Technology used to build the application is Spring with Axon and for messaging usign RabbitMQ

Step 1 -

A shop is registered by issue a command ShopRegisrtraionCommand (ofcourse this handle by the shop aggregate and change the status when event is fired) , which fire an event ShopRegistratedEvent .

Step 2 -

When shop ShopRegistredEvent is fired , then I have a EventHandler which listen ShopRegistredEvent and send the SendEmailVerificationCommand (you can say a request or it act as request )to NotifyService.

Step 3 -

The same command (SendEmailVerificationCommand ) is also handle by the Shop aggregate and then shop aggregates fire an event MailVerifcationSendedEvent, this event changes the verification status of Shop to "MailInSendingProcess".

Step 4 - On other side NotifyService handle that command (SendEmailVerificationCommand or request ) and send the mail , if the email successfully sent then NotifyService fire a VerificationEmailSent.

Step 5 -

VerificationEmailSentEvent (fired by NotifyService) is listen by ShopManagment Application using the event listener , then this event listener issue a VerificationMailSendedSuccesfullyCommand for the shop aggregates, and then shop aggregate fire an event VerificationEmailDeliveredEvent , this changes the verifcation status "MailDelivered".

Step 6 -

If the mail sending failed due to any reasons , NotifyService fire another event VerificationEmailSendingUnsuccessfullEvent which handle by ShopManagament event listener and issue a another command VerificationEmailUnsuccessfull to shop aggregate and then shop aggregate fire an event VerficationMailSendingFailedEvent , this event change the status of verification status to "MailSendingFalied".

Here the two BC communicate using request and event.

Question -

1. Can we send command to other bounded context as I am sending in my application or there is another approach.
2. Is the tracking the status of the Email sending is part of Shop aggregate or I have to create the another aggregate like EmailVerifcation because I have to resend the falied mail using the schedular.
3. Is any other way to manage this type of thing if happinning?

Answer 1

I have seen this back and forth between services for verification happen before, but it is typically a process I'd prefer to avoid. It requires intricate teamwork with services for something relatively simple; the intricacy will typically cause pain in the future.

Now to answering your questions:

1. This should be fine I'd say. A Command is nothing more then a form of message, just like queries or the events in your system. The downside might be that the command-sending Bounded Context should be aware of the 'language' the other Bounded Context speaks. Some form of anti corruption layer might be in place here. See of this as a service which receives the command-sending request of BC-1 in its language and translates it to the language of BC-2. From an Axon Framework perspective I'd also recommend to setting up the DistributedCommandBus, as it contains a component (the CommandRouter to be precise) which is aware of what commands which node might handle.

2. & 3. This wholly depends on how your domain is modeled. On face value, I'd say a Shop aggregate typically isn't aware of any emails being sent, so from that end I'd say 'no, don't include it in the aggregate'. A Saga would likely be a better fit to send a command to your NotifyService. That Saga would listen to the ShopRegistredEvent and as a response would publish the SendEmailVerificationCommand to the NotifyService. The Saga is able to either act on the callback of the SendEmailVerificationCommand or handle the VerificationEmailSentEvent and VerificationEmailSendingUnsuccessfullEvent to perform the required follow up logic after a (un)successful email.

Hope this gives you some insights Ashwani!