Comparison
Dependency inversionvsHexagonal architecture
Dependency inversion
the business rules import the Postgres driver, so testing a discount calculation needs a database.
Making the important code depend on an interface it defines, and the infrastructure depend on that interface too, so the arrow points inward instead of outward. The practical effect is that the rules of your business can be tested and understood without a network, a database or a cloud account. It is the backbone of the ports-and-adapters argument, and the reason a senior engineer will push back on a domain object that knows what a HTTP status code is.
Full entry →Hexagonal architecture
the same use case runs from an HTTP handler, a message consumer and a test, and none of them is the primary one.
An arrangement where the application defines ports — interfaces for what it needs and what it offers — and adapters implement them for HTTP, databases, queues or tests. The hexagon shape carries no meaning beyond having several sides; the content is that the application never depends on a delivery mechanism or a storage technology. It makes the application testable in isolation and adds an interface plus an adapter for every boundary, which is real work for a small service.
Full entry →