How should AWS Lambda functions subscribe to domain events?

Question

I'm doing my first Domain Driven Design (DDD) implementation. My architecture is comprised of .Net Core for defining my domain model, services, and building AWS Lambda functions. I am using Lambda functions as entry points to functionality into each bounded context.

In researching DDD, I've learned one approach for communication is publishing events from a bounded context allowing subscribers (within same bounded context, or external bounded contexts) to listen for and act upon the published event. I'm looking at Mediatr as a possible mechanism for publishing/subscribing to domain events.

I'm having a hard time connecting/understanding how to implement Mediator pattern using Mediatr for publishing/subscribing to events in a serverless environment. Specifically, how do I use Mediatr to publish an event and have a Lambda function subscribe to and act upon the event when it happens?

I know AWS offers Simple Notification Services (SNS) and Simple Queue Service (SQS) as means for notifications and these services can kick-off a Lambda function. I also know I can kick-off a SNS request from .Net Core. So, in my .Net Core code, should I simply replace Mediatr with calls to either SNS or SQS?

It seems to me SNS/SQS is an approach to the Mediator pattern allowing me to decouple my bounded contexts. If SNS/SQS is how you implement Mediator pattern within AWS & Lambda environment, then is Mediatr relegated for use in more traditional hosted applications?

Thank you for your time.

Answer 1

We do some event processing at very low scale using AWS and a "push" model. Roughly, the design looks like this:

SNS is used by a publisher to `fan-out`

SQS is used by a subscriber to `fan-in`

Triggers are used to fire the subscriber function when there is work available in the queue.

When we deploy a new lamdba, the same template that creates the function also creates the queues and the subscriptions between the queues and the topics. Most updates from that point forward are just deploying new implementations of the function.

Environment variables are used to communicate to the publisher which topics should be used for broadcasting events.

This is fine, at our timid scale, so long as the messages flow without interruption. Note that this design by itself doesn't give us any way to access messages that were broadcast before the subscription was created, or recover "lost" messages.

If you have copies of the messages you need, you can of course send them to SQS "by hand". One thing I ended up doing in my case -- purely for symmetry -- was creating a subscription from my queue to a "manual" topic, so that I could broadcast events using the SNS API and have them look as though they came from some SNS capable publisher.

(It might be better to implement a lambda that can discriminate between different message types; that was plumbing I wasn't particularly interested in for my case).