Think of building a restaurant.
Domain-Driven Design (DDD) is about deciding how the restaurant works.
Hexagonal Architecture is about deciding how the building is laid out so you can swap the kitchen equipment, cash register, or delivery service without changing how the restaurant operates.
They're related, but they solve different problems.
Domain-Driven Design (DDD) — "Focus on the business"
Imagine you're building software for a library.
Most beginner code looks like this:
Button clicked
↓
SQL query
↓
Calculate late fee
↓
Update database
Business rules end up scattered everywhere.
DDD says:
Put all the business knowledge in one place.
For example:
Instead of
if book.days_late > 14:
fee = days * 2
inside a controller...
You create something like
Book
Return()
LateFeePolicy
CalculateFee()
Member
BorrowBook()
Now the code reads like the business.
Someone from the library can even understand the names.
The "Domain"
The domain is simply:
The problem your software exists to solve.
Examples:
- Banking → transferring money
- Hospital → scheduling patients
- Amazon → selling products
- Chess → game rules
Everything else is supporting stuff.
DDD says
Business rules should be the center of your application.
Not:
- databases
- web frameworks
- APIs
- React
- HTTP
Those are details.
Hexagonal Architecture — "Protect the business"
Now imagine your restaurant.
Customers enter through the front door.
Suppliers enter through the back door.
Employees use another entrance.
But once inside...
They all interact with the same kitchen.
Customer
\
Phone App ---> Kitchen <--- Supplier
/
Website
The kitchen doesn't care who came in.
That's Hexagonal Architecture.
Instead of your code looking like
React
↓
Express
↓
SQL
It looks like
React
\
CLI -----> Business Logic <----- Tests
/
API
Everything talks to the business layer.
The business layer talks to nobody.
Ports and Adapters
This is the weird terminology everyone gets stuck on.
Imagine charging your phone.
Your phone has:
Port
USB-C hole
Chargers are
Adapters
Wall charger
Laptop charger
Battery pack
Car charger
The phone only knows:
"Give me power."
It doesn't care where it comes from.
Software is the same.
Your business says:
SaveCustomer()
That's the port.
The database implements it.
Postgres
MongoDB
SQLite
Memory
Those are adapters.
Swap one.
Business doesn't change.
Example
Suppose your business rule is
Withdraw money
Business logic:
Withdraw(account, amount)
if balance < amount
fail
balance -= amount
save(account)
Notice there's no SQL.
No HTTP.
No JSON.
Just banking.
Database adapter:
save(account)
might become
UPDATE accounts...
API adapter
POST /withdraw
calls
Withdraw()
CLI adapter
withdraw --amount 100
also calls
Withdraw()
Same business code.
Different entry points.
How DDD and Hexagonal fit together
DDD tells you:
Organize your code around business concepts.
Hexagonal tells you:
Keep those business concepts isolated from technology.
Think of it like this:
React
|
REST API
|
-----------------------
Business Domain (DDD)
Account
Customer
Invoice
Order
Payment
-----------------------
Database
Email
Stripe
RabbitMQ
Everything outside can change.
The middle should barely notice.
Why people like this
Imagine your boss says:
"We're replacing PostgreSQL with MongoDB."
Without Hexagonal Architecture:
😱 200 files changed
With Hexagonal:
Replace one adapter.
Done.
Or:
"We're making a mobile app."
You don't rewrite business logic.
The app just becomes another adapter.
The 30-second summary
- DDD answers: "How should I model the business?" It organizes code around real-world concepts like
Order, Invoice, and Customer, and keeps business rules together.
- Hexagonal Architecture answers: "How do I keep the business independent of frameworks and infrastructure?" It places the business logic at the center and connects databases, APIs, UIs, and external services through well-defined interfaces (ports) and implementations (adapters).
A useful mental model is:
DDD defines what's inside the kitchen. Hexagonal Architecture decides how everyone enters the kitchen without changing how it cooks.
