
Hexagonal Architecture in Practice
How to implement hexagonal architecture (ports and adapters) in a real application — separating business logic from infrastructure with clear boundaries, dependency inversion, and testable core domains.
Categories
Systems & patterns · 39 articles · Page 3 of 4

How to implement hexagonal architecture (ports and adapters) in a real application — separating business logic from infrastructure with clear boundaries, dependency inversion, and testable core domains.

How to design a plugin system that lets users extend your application without modifying its core — covering plugin interfaces, lifecycle hooks, dependency resolution, and sandboxing.

A practical guide to consensus algorithms — covering Raft, Paxos, and leader election patterns with real-world examples of when and why distributed systems need them.

A practical guide to event sourcing — when to use it, how to implement event stores, build projections, handle schema evolution, and avoid common pitfalls.

How API gateways handle routing, authentication, rate limiting, and response aggregation — with patterns for building or choosing the right gateway for your architecture.

A comparison of threading, async/await, and actor-based concurrency models — when each fits, their tradeoffs, and how to avoid common pitfalls.

How to implement timeouts, retries, and backoff strategies that prevent cascading failures in distributed architectures.

A service mesh moves networking concerns like retries, circuit breaking, mTLS, and observability out of application code and into the infrastructure layer.

When a downstream service is failing, continuing to send requests makes everything worse — the circuit breaker pattern stops the cascade by failing fast.

Command Query Responsibility Segregation uses different models for reading and writing data — here's when it solves real problems and when it's unnecessary complexity.

Entities, value objects, aggregates, and bounded contexts — the DDD patterns that keep complex business logic organized without over-engineering simple systems.

Event-driven systems decouple producers from consumers through asynchronous message passing — but eventual consistency, ordering guarantees, and idempotency introduce real complexity.