arch-layered

One-line summary

Organize the system into horizontal layers (typically Presentation → Business → Persistence → Database). Dependencies flow strictly downward; upper layers depend on lower layers, never the reverse.

When to use this skill

• A simple monolith with clear UI / business-logic / data separation.
• A team's first server-side architecture — layered is the easiest mental model.
• A system where the dominant change axis is "swap the UI" or "swap the database" (within reason).
• When constraints (regulatory, team-size, deployment) make microservices or event-driven overkill.

When NOT to use this skill

• The domain model is rich enough that the business layer becomes the bottleneck and should drive every other layer — consider arch-hexagonal (which inverts the dependency direction to keep the domain at the centre).
• The system genuinely needs independent scaling, deployment, or data ownership per business capability — see arch-microservices.
• The dominant communication pattern is asynchronous and event-shaped — see arch-event-driven.

Core content