When developers hear “port,” most think interface.
Add an interface, call it a port, check the box.
But here’s the trap: just adding interfaces doesn’t make your domain independent.
Abstraction alone doesn’t automatically enforce architecture.
If your dependencies point the wrong way, your domain depends on the database, API, or external services — instead of defining what the system should do.
In Hexagonal Architecture, the question isn’t just “do I have a port?”
It’s: who does the domain call, and who implements it?
Do your dependencies point the right way?
🚀 Register now: Acceptance Testing Workshop
Get 100 EUR off with code EARLYBIRD100
❌ Domain depends on Infrastructure
Domain directly uses infrastructure classes like
JpaOrderRepositoryorPaymentApiClientBusiness logic becomes tied to storage or APIs
Changing the database or API can break domain code
✅ Domain defines the contract, infrastructure implements the contract
Domain defines driven ports — interfaces that describe what it needs done
Driven adapters implement the details
Domain logic is stable, infrastructure can change without affecting it
Driven ports exist to control this dependency direction.
Abstraction alone doesn’t enforce architecture — direction does.
Real-life Example: Ordering System
Applying Hexagonal Architecture on the backend (for an e-commerce system).