Use Case

Hexagonal Architecture in AWS

The hexagonal architecture pattern (aka ports and adapters pattern) was introduced by Dr. Alistair Cockburn in 2005. It decouples business logic from external components like databases and UIs, allowing systems to adapt easily to technology changes without impacting core logic.

In this loosely coupled architecture, the application communicates with external components via ports, and adapters translate the technical exchanges with these components.

When to use ?

• You want to isolate parts of your app for easier independent testing.

• Different clients (like APIs or message queues) need to share the same core logic.

• Your UI or database requires frequent updates without impacting the main logic.

• Your app has multiple inputs and outputs, and changes to the logic make the code harder to maintain or scale.

Example Architecture Designs:

To implement hexagonal architecture on AWS, start with a simple design for a MVP. Most microservices need three layers: a client entry point, a compute layer, and a data storage layer.

AWS services fit into these roles as follows:

• Clients: API Gateway, SQS, ELB, EventBridge.

• Primary Adapters: Lambda, ECS, EKS, EC2.

• Secondary Adapters: DynamoDB, RDS, Aurora, API Gateway, SQS, ELB, SNS, EventBridge.

1. Simple Design

In this example, API Gateway is the client (REST API), Lambda is the primary adapter (compute), and DynamoDB is the secondary adapter (persistence).

The gateway client triggers the Lambda handler as the entry point. The architecture is serverless, using the command pattern for easy maintenance and scalability in microservices.

2. CQRS pattern

This CQRS pattern example uses two Lambda handlers: one for handling queries synchronously via API Gateway (client) and one for processing commands asynchronously through Amazon SQS (client).

Both clients use Lambda as the primary adapter. The architecture includes multiple clients and entry points (Lambda handlers), all within the same bounded context and domain, making it a scalable, fully serverless setup.

3. Evolving the Architecture with Containers, Relational Databases, and External APIs

In this setup, ECS is the primary adapter for managing long-running tasks, triggered by EventBridge. RDS is introduced as the secondary adapter to handle relational data storage, while an additional API Gateway serves as another secondary adapter to manage external API calls.

All components are loosely connected to the domain via ports, which allow flexibility in changing adapters without impacting the core logic. For instance, switching from DynamoDB to RDS is seamless by just adding a new adapter, maintaining the domain's independence from specific technologies.

This design leverages different compute layers to support diverse workloads under the same business domain.

4. Add More Domains

Hexagonal architecture aligns well with microservices. The examples so far showed a single domain, but applications usually have multiple domains that communicate using primary and secondary adapters.

Each domain represents a microservice and is loosely connected to others. Each domain can have its own compute environment, or multiple, and uses defined interfaces to communicate with other domains through ports.

These ports use primary and secondary adapters, so changes to adapters don’t affect the domains, keeping them decoupled.

In the example, primary adapters include Lambda, EC2, ECS, and Fargate, while secondary adapters include API Gateway, Elastic Load Balancing, EventBridge, and SQS.

My 2 Cents 🪙 🪙 

Hexagonal architecture works well with domain-driven design, keeping sub-domains loosely connected and making testing easier.

But it can add complexity, extra maintenance, and some delay because of the added layers. It’s all about trade-offs.

Architecture designs are subjective art ! do it with 💗 

Trends & Updates

Resources & Tutorials

With that, it's time to wrap up. Got to get ready for tomorrow!