SoC: Separate Different Reasons to Change
An interface, business rules, data storage, and integrations change for different reasons. When they're mixed in one module, any change starts to touch everything: editing the response format hits business logic, swapping storage hits validation. Separation of Concerns proposes splitting parts precisely by reasons to change, not by file types.
Importantly, a good boundary doesn't necessarily mean a new service or folder. Sometimes a separate function, module, or an explicitly stated contract is enough. The goal isn't to multiply layers but to make one reason to change live in one place.
A boundary is checked by one question. It's useful if it lets you change one business reason without opening another's files. If changing delivery rules means digging into the discount code, the boundary is drawn in the wrong place.
To run a specific situation through this criterion and see whether a boundary is needed already, use the lab.
Do you need a boundary?
Draw the boundary: the parts change for different reasons. A function, module, or contract is enough.
By what criterion do you draw a boundary (SoC)?
SoC says WHAT to separate - by reasons to change. SOLID helps design HOW to draw those boundaries in classes and modules.