Architecture Boundaries
Layered, hexagonal, clean and onion compared honestly — plus adapters and anti-corruption layers, which are the part that survives whichever style you pick.
Domain, application, infrastructure and transport is a useful model of where the seams fall inside a codebase. It is one model, not universal truth, and saying so is the lesson.
An application core that declares the interfaces it needs, and adapters on the outside that satisfy them. An ordinary dependency-direction choice, worth its cost exactly where the outside varies.
Policy inward, details outward. One approach among several — and the one most often adopted whole, at a ceremony cost nobody prices before committing.
Concentric rings with the domain model at the centre. Nearly the same idea as hexagonal and Clean, drawn differently — and saying so is more useful than pretending they are three schools.
Translate external formats into your own model at the edge, once. The rule that keeps a vendor SDK's types from spreading through code that has nothing to do with the vendor.
When the other system's concepts are wrong for you — not just its formats — translate the model, not the fields. The layer exists so their vocabulary cannot colonise yours.