I really like this article. To your conclusion, I think it's common for people to think that a specific lambda function is an event handler and therefore they must pile all this logic into a single layer.
In fact, the actual handler layer, the part that receives the event, should be really thin.
All the goodness of the hexagonal architecture can be modelled as layers (loaded language, I don't mean a Lambda Layer, I mean a code layer) that are simply triggered by the event the handler receives.
The lambda becomes a mini-hexagonal app in itself. We typically have the following
handler - receives and validates the event
services - apply business logic
data-access-layer - abstraction/port for accessing an external API
transit - connections to external APIs (databases, 3rd party systems etc)
We'll then have multiple handlers with an app, which typically share the data-access-layer and transit, sometimes services but they're all bundled separately so we get the benefit of treeshaking.
I never got notified for that comment so apologies for the comically late response.
I cannot agree more. I find that there's many different words for describing the same thing which different people understand them differently which ends up with confusion.
I have been aware of the domain driven design approaches for a while but Hexagonal architecture was my first hands-on experience with one of them. It slightly complicates things at the beginning but once you get the idea it makes perfect sense.
The multiple handlers that you mentioned is a perfect example of an approach that might be confusing once you first come across it but it is a great way of abstracting components with similar functionality and therefore using the same domain logic.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I really like this article. To your conclusion, I think it's common for people to think that a specific lambda function is an event handler and therefore they must pile all this logic into a single layer.
In fact, the actual handler layer, the part that receives the event, should be really thin.
All the goodness of the hexagonal architecture can be modelled as layers (loaded language, I don't mean a Lambda Layer, I mean a code layer) that are simply triggered by the event the handler receives.
The lambda becomes a mini-hexagonal app in itself. We typically have the following
handler - receives and validates the event
services - apply business logic
data-access-layer - abstraction/port for accessing an external API
transit - connections to external APIs (databases, 3rd party systems etc)
We'll then have multiple handlers with an app, which typically share the data-access-layer and transit, sometimes services but they're all bundled separately so we get the benefit of treeshaking.
I never got notified for that comment so apologies for the comically late response.
I cannot agree more. I find that there's many different words for describing the same thing which different people understand them differently which ends up with confusion.
I have been aware of the domain driven design approaches for a while but Hexagonal architecture was my first hands-on experience with one of them. It slightly complicates things at the beginning but once you get the idea it makes perfect sense.
The multiple handlers that you mentioned is a perfect example of an approach that might be confusing once you first come across it but it is a great way of abstracting components with similar functionality and therefore using the same domain logic.