Layering

Layering separates UI, application orchestration, domain rules, persistence, and integration concerns so each change stays localized. Good layers are defined by responsibility and change rate, not by folder names alone. A presentation layer should not embed SQL; domain policy should not depend on HTTP status codes.

On interviews: explain when layering pays off versus when it becomes ceremony. Mention dependency direction inward and where transaction boundaries live.

Common pitfalls: anemic domain models with all logic in services; layers that leak types across boundaries; duplicate DTO mapping with no clear owner.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Name responsibilities and allowed dependencies per layer.
• Keep domain rules free of framework imports.
• Place integration and I/O at the outer edge.
• Justify each layer with a real change scenario.