使用 AWS Lambdas 而不是微服务时，如何在事件溯源中实现聚合之间的通信

Question

So I have a background in working with event sourcing and microservices. And usually the best way to enforce bounded context yet be able to make your aggregate communicate is to have either some kind of Choreography or some kind of Orchestration.

In a Choreography Aggregate A will raise eventA that Aggregate B will listen to and handle and then after doing whatever needed to be done, it will raise eventB and A will listen and handle it and proceed. It's effective, respects event-sourcing and DDD rules.

In an Orchestration, Aggregate A will raise eventA that the orchestrator O will listen and handle and then issue a command B to Aggregate B which in return will run what's needed and raise Event B, orchestrator O will handle that event and issue a command A and so on... It adds a level of complexity but it's great for an added level of segregation, also this way Aggregate A and B are not listening/handling each other events.

Obvs these 2 methods have their own pros and cons, but both work perfectly in a microservice context.

The issue I'm facing is that for me there is no context. I'm working with AWS lambdas, whenever an event is pushed to the store I will have a lambda listening to db(event store) changes and then do something. It was working perfectly until I needed to add a second aggregate.

And now to achieve a choreography or an orchestration, I either need a context(which is not a thing for lambdas) and an event bus, or I need to add a lambda for every event, that would lead for total chaos.

Like if Aggregate A needs something from Agg B before continuing its flow it will push an event to the event store and I will have to handle the event with a new lambda so for every type of interaction between Agg A and Agg B, I will need 2 lambdas.

Maybe I'm missing something, after all I'm new in AWS lambdas and more used to working with microservices.

Answer 1

Perhaps what you're after is a Process Manager:

(…) a process manager is a class that coordinates the behavior of the aggregates in the domain. A process manager subscribes to the events that the aggregates raise, and then follow a simple set of rules to determine which command or commands to send. The process manager does not contain any business logic; it simply contains logic to determine the next command to send. The process manager is implemented as a state machine, so when it responds to an event, it can change its internal state in addition to sending a new command.

The above definition can be found in Microsoft's Exploring CQRS and Event Sourcing . This is a way of having orchestration in an event-driven system. The original definition, AFAIK, can be found in Gregor Hohpe's Enterprise Integration Patterns .

In AWS land, you'd have your lambda(s) reacting to those events and firing off commands (either via a command bus, if you have such concept in your system, or by directly invoking other lambdas).