Ports and Adapters for Domain Isolation
Decouple business logic from frameworks by depending on abstract ports instead of concrete infrastructure.
Why Isolate the Domain?
In an enterprise NestJS backend, your most valuable code is the business logic: pricing rules, eligibility checks, workflow state machines. This logic should outlive any specific database, message broker, or HTTP framework.
The Ports and Adapters pattern (also called Hexagonal Architecture) achieves this by inverting dependencies. The domain defines abstract ports (interfaces) describing what it needs. Concrete adapters (Postgres, Redis, Stripe) implement those ports and plug in from the outside.
- The domain depends on nothing external.
- Infrastructure depends on the domain, never the reverse.
The Dependency Rule
The core invariant is a one-way dependency arrow: infrastructure → application → domain. Source-code imports may only point inward.
A domain entity must never import from @nestjs/common, TypeORM, or an HTTP client. If it does, you have coupled your rules to a framework's release cycle and made them hard to test in isolation.
Ports live inside the boundary; adapters live outside it. The interface (the port) is owned by the domain, so the domain dictates the contract and the outside world conforms to it.
All lessons in this course
- Ports and Adapters for Domain Isolation
- Dynamic Provider Registration with DiscoveryService
- Lazy-Loaded Modules and Feature Toggles
- Extension Points with the Module Reference API