Book 09 · Software ArchitecturePage 37 of 48

Separation of Concerns

In Turkish: İlgilerin Ayrılması

Updated September 30, 20262 min read

In short

Separation of concerns is a design principle that divides a program into distinct parts, each responsible for one clearly defined aspect of its behavior.

What is separation of concerns?

Separation of concerns means organizing code so that each part deals with one concern, meaning one area of responsibility, such as displaying data, applying business rules, or saving to a database. The term was coined by computer scientist Edsger W. Dijkstra in 1974. When concerns are separated, you can understand, change, or test one part without having to think about all the others.

The principle shows up at every level of software. On the web, HTML handles structure, CSS handles presentation, and JavaScript handles behavior; in applications, patterns like MVC separate data, display, and input handling; and in larger systems, separate services handle separate business capabilities. At the smallest level, a function that does one thing well is separation of concerns in action.

A restaurant kitchen is a good analogy: one station prepares salads, another grills, and another makes desserts. Each cook can focus on one job, a problem at the grill doesn't ruin the desserts, and one station can be improved without retraining everyone. In code, the same separation means a change to the database layer shouldn't require rewriting the user interface.

Separation of concerns is broader than the Single Responsibility Principle from SOLID, which applies the same idea specifically to classes and modules. It is also not about separating file types for their own sake: component-based frameworks often keep the markup, styles, and logic of one component together, because the component itself is the concern. The goal is low coupling between parts and high cohesion within each part.

Key takeaways

Each part of a program should handle one concern, or responsibility.
It makes code easier to understand, test, change, and reuse.
It applies at every level: functions, modules, layers, and services.
The Single Responsibility Principle is a specific form of this idea.
Aim for low coupling between parts and high cohesion within them.

Example

Mixed versus separated concernsjavascript

// Mixed concerns: fetching, business rules, and display in one function
async function showCartTotalMixed() {
  const items = await (await fetch("/api/cart")).json();
  const total = items.reduce((sum, item) => sum + item.price * item.qty, 0);
  document.querySelector("#total").textContent = total.toFixed(2);
}

// Separated concerns: each function has one job and can be tested on its own
const fetchCart = async () => (await fetch("/api/cart")).json();
const calculateTotal = (items) => items.reduce((sum, i) => sum + i.price * i.qty, 0);
const renderTotal = (total) => (document.querySelector("#total").textContent = total.toFixed(2));

async function showCartTotal() {
  renderTotal(calculateTotal(await fetchCart()));
}

Readers ask

What is the difference between separation of concerns and the Single Responsibility Principle?

Separation of concerns is a general principle that applies at any level of a system, from functions to entire services. The Single Responsibility Principle is a narrower rule from SOLID stating that a class or module should have only one reason to change.

What is an example of separation of concerns?

A classic example is a web page, where HTML defines the structure, CSS controls the appearance, and JavaScript adds behavior. Another is MVC, which separates data and business rules, presentation, and input handling.

Why is separation of concerns important?

It limits how far a change can spread, so you can update one part of a system without breaking others. It also makes code easier to test, because each part can be checked on its own.