Separation of concerns
Separation of concerns is a software-design principle that keeps different kinds of responsibilities in different parts of an application.
For example, the code that applies a business rule can be kept separate from the code that displays information to a user or reads and writes information in a database. Each part can focus on its own job and communicate with the others through clearly defined boundaries.
This does not necessarily mean that every responsibility needs its own application or service. It means organizing the software so that a change in one area does not require unnecessary changes throughout the rest of the system.
Why is separation of concerns useful?
Separation of concerns can make software:
- easier to understand and maintain;
- easier to test;
- safer to change; and
- less dependent on a particular technology or vendor.
For a small or midsize business, that last benefit can be especially important. A database, payment processor, accounting system, or other technology may eventually need to be replaced. When the code that interacts with it is kept separate from the application’s business rules, the change is usually smaller and less risky.
There is a balance to strike. Dividing a simple application into too many layers or services can make it harder rather than easier to understand. The goal is not to create the most elaborate architecture possible, but to keep parts that change for different reasons from becoming unnecessarily tangled together.