Layered architecture
Skill Amey-Thakur/AI-SKILLS/skills/architecture/layered-architecture
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill layered-architectureAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Organize a system into layers with one permitted direction of dependency and enforce that direction mechanically at the import level. Use when a codebase is sliding toward tangled cross-references and you need a rule a linter can check, not a convention people forget.
SKILL.md
2.8 KB, 545 tokens by cl100k_base, as published. Nobody here has run it
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
- 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.
- 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.
- 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.
- 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.
- Ban skip-layer calls too. Presentation talking straight to infrastructure defeats the point as surely as an upward import. Allow each layer to see only the one directly beneath it unless you decide otherwise.
- Map data at the seams. Convert ORM entities to domain models and domain models to response DTOs at the boundary, so a persistence detail cannot leak three layers up and pin the whole stack to your database vendor.
Signals
- Does the import linter run in CI and fail on a violation, or is layering just a diagram in the wiki?
- Can you swap the web framework without touching the domain package?
- Does any file import from a layer more than one level away?
Boundaries
For a small service the ceremony can cost more than the tangle it prevents: reach for layers when the module count and team size make ad hoc references unsafe. Hexagonal architecture is a stricter relative that isolates the domain behind explicit ports: prefer it when the domain is the asset worth protecting.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.