Architecture as Boundaries
The most durable architectural choices are the ones that make unwanted dependencies hard to add.
Architecture is often described in diagrams, but the real decisions live in dependency rules. Which packages may import which, where data changes shape, and who owns a transaction are more consequential than the names of layers. A simple diagram with clear boundaries beats an elaborate one that nobody enforces.
Boundaries should be visible in the code. If a rule matters, make it awkward to break: keep internal types unexported, put adapters at the edge, and let the compiler complain when someone reaches across a line. The goal is not to prevent every mistake, but to make the common path the safe one.