Separation of concerns

Separation of concerns is a design principle: split a system into parts that each address one reason to change—UI vs domain logic vs persistence, or routing vs validation vs business rules—so edits stay localized and tests stay focused. It is the informal umbrella behind layered architectures, modules, and boundaries like CQRS when read and write concerns diverge. Push it until cohesion drops or indirection explodes; “perfect” layers are not the goal—maintainability is.