Separation of Concerns
Organising a system so each part addresses one concern, and a change to that concern touches one part.
The test is not "does this component do one thing" — that is too vague to apply. It is: when this concern changes, how many places do I have to edit? If changing the tax rules means touching the UI, the service layer and three reports, tax is not a separated concern.
Concerns are separated at every scale: functions, modules, services, and whole systems. The scale that matters architecturally is the one where the concerns are owned by different people or change on different schedules.
The failure mode is separating along the wrong axis. Splitting by technology (controllers, services, repositories) separates technical concerns while leaving every business concern smeared across all three layers — which is why a layered architecture makes a feature change touch every layer.