intermediate
Separation of Concerns
Separate responsibilities such as UI, orchestration, domain rules, persistence, and integration so each can change for its own reason.
Separation of Concerns divides a system so each part addresses a distinct concern—UI rendering, application orchestration, domain rules, persistence, integration with third parties. Changes to HTML layout should not force edits to SQL queries when layers are clean.
SoC appears horizontally (layers) and vertically (feature slices); both reduce blast radius.
On interviews: map concerns in a messy full-stack handler and propose layer boundaries.
Common pitfalls: strict layering that forbids pragmatic shortcuts, anemic domain with all logic in controllers, and cross-layer imports bypassing public APIs.
The trade-off is navigation overhead across files versus isolated change and clearer testing seams.
Checklist:
- List concerns that change independently.
- Enforce dependency direction inward to domain.
- Expose narrow module APIs.