Laws of Software Engineering · Pattern
Pattern
Hexagonal Architecture (Ports and Adapters)
Put the domain at the centre. Surround it with ports (the contracts the domain offers) and adapters (the code that connects ports to the outside world).
How to use it. When the domain logic keeps getting tangled with database, UI, or framework concerns, the architecture is leaking. Push everything outward into adapters. The domain should be testable without any of them.
How it gets misused. Treated as an excuse for ceremony. Five adapters and three ports for a simple CRUD service is theatre. The architecture pays off where the domain is genuinely complex and the surrounding tech changes faster than the rules.
Related
- Principle Bounded Contexts Different parts of a system can use the same word to mean different things. Draw an explicit boundary around each meaning and translate at the seam.
-
Principle
SOLID
Five rules for designing object-oriented code: each class does one thing, code should be open to extension but closed to modification, subclasses should be substitutable, interfaces should be small, and code should depend on abstractions rather than specifics.
Clusters
- The Code Design cluster - How to write code that survives change.