Definition
Separation of concerns is the principle of decomposing a system so that each part addresses a single, distinct concern — one well-defined responsibility — with as little overlap as possible between parts. A concern is any cohesive aspect of the problem: persistence, presentation, validation, scheduling, or a single business rule.
When concerns are cleanly separated, each part can be understood, changed, and tested on its own terms. When they are tangled, a single edit must reason about several unrelated responsibilities at once, and a change made for one reason risks breaking another. Separation of concerns is foundational across software engineering precisely because it is the lever that keeps a growing system comprehensible.
Why it matters
How it works
One concern, one place
The working test is to ask, for each module, what single reason would force this to change? If a part would change for two unrelated reasons — say, because the database schema changed and because the report layout changed — those are two concerns that belong in two places. Splitting them means each future change has an obvious, contained home.
Boundaries and interfaces
Concerns are separated by drawing a stable interface between them. One part exposes what it does without revealing how, and its neighbors depend only on that contract. This is where separation of concerns meets decoupling and encapsulation: the boundary both isolates the concern and hides the variation inside it, so the rest of the system is shielded from its internals. Design patterns are largely catalogued ways of placing these boundaries well — a Strategy separates an algorithm from its user, an Observer separates an event from its reactions.