layered-architecturelisted

# Layered architecture Layers are only useful if the arrows point one way. The moment the database layer imports the web layer "just this once," the structure stops being a structure and becomes decoration on a ball of mud. The discipline is not drawing the diagram: it is refusing every dependency that runs uphill. ## Method 1. **Name the layers and fix the direction.** A common stack is presentation over application over domain over infrastructure, with dependencies allowed to point down only. Write the direction down before you write code, because every later argument is settled by this one sentence. 2. **Give each layer its own module namespace.** One package or directory per layer, so a dependency across layers is a visible import statement, not a buried function call. If layers share a namespace, no tool can see the boundary and neither can the reviewer. 3. **Invert dependencies that need to point up.** When the domain needs to save data, it defines a repository interface and infrastructure implements it. The arrow at compile time still points down even though control at runtime flows out. This is the one move that keeps the domain framework-free. 4. **Enforce the direction in CI, not in review.** Wire up import-linter (Python), ArchUnit (Java), dependency-cruiser or eslint-plugin-boundaries (JavaScript), or Go's internal packages. Fail the build on an upward import. A rule humans police is a rule that erodes on the busy week. 5. **