Separation of Concerns

What counts as a 'concern'

A concern is a distinct aspect of the work — one reason the code might need to change. In a typical request handler you can usually spot four:

• Validation — is the input well-formed and allowed? (empty email? password too short?)
• Business logic — the actual rules of your product. (a new user starts on the free plan; block disposable email domains)
• Data access — talking to storage. (insert the row, read it back, handle a duplicate key)
• Presentation — shaping the output. (build the JSON, render the HTML, pick the status code)

Each of these changes for a different reason and at a different time. The validation rules come from product. The database choice comes from infrastructure. The page layout comes from design. When they share a function, a change to any one of them puts the others at risk.

The smell: one function doing everything

Here is the trap, and it is the natural first draft everyone writes — the four concerns interleaved line by line:

function handleSignup(req) {
  if (!req.email.includes("@")) return res(400, "bad email");   // validation
  if (req.password.length < 8)  return res(400, "weak password"); // validation
  const plan = "free";                                            // business
  if (blocked(req.email))       return res(403, "blocked domain");// business
  db.query("INSERT INTO users (email, plan) VALUES (?, ?)",       // data access
           [req.email, plan]);
  const user = db.query("SELECT * FROM users WHERE email = ?",    // data access
                        [req.email]);
  return res(200, "<h1>Welcome, " + user.email + "!</h1>");       // presentation
}

It works. But it is welded together. Want to move from MySQL to Postgres? You are editing the same function that holds your validation and your HTML. Want to unit-test the signup rules without a database? You can't — the rules and the db.query calls live on adjacent lines. Want to return JSON for a mobile app and HTML for the web? Now the presentation logic is tangled in too. One concern can't move without disturbing the others.

The fix: give each concern its own part

Pull each concern into its own module with a clear, narrow job. The handler becomes a short coordinator that calls them in order:

// validation.ts  — one concern: is the input OK?
export function validateSignup(req) { /* ...checks, throws on bad... */ }

// signup-service.ts — one concern: the business rules
export function signup(email) { return users.create(email, "free"); }

// users-repo.ts — one concern: talking to storage
export const users = { create(email, plan) { /* db insert + read back */ } };

// presenter.ts — one concern: shaping the output
export function welcomeHtml(user) { return `<h1>Welcome, ${user.email}!</h1>`; }

// handler.ts — a thin coordinator that wires the concerns together
function handleSignup(req) {
  validateSignup(req);
  const user = signup(req.email);
  return res(200, welcomeHtml(user));
}

Now each part has one reason to change. Swap the database? You touch only users-repo.ts. Tweak a validation rule? Only validation.ts. Add a JSON response? Add a presenter — the rules and storage never notice. The pieces are also reusable (the validator can guard other endpoints) and testable in isolation (test the business rules with a fake repo, no real database).

Layering: the most common way to separate

The classic shape is layers, stacked so each only talks to the one below it: Presentation (what the user sees) → Domain / Business Logic (your rules) → Data Access (storage). This is sometimes called presentation–domain–data layering. The point of the stack is that a concern is sealed off: the presentation layer never writes SQL, and the data layer never builds HTML.

Why this is the whole point

• Change safely — touch one concern, leave the rest alone. Swapping the database can't break your validation if they live in different modules.
• Test in isolation — unit-test the business rules with a fake repository: no database, no network, fast and deterministic.
• Reuse — a sealed-off validator or presenter can be reused by other endpoints instead of being copy-pasted out of a giant function.
• Understand faster — to fix an HTML bug you open the presentation module, not a 200-line function where everything is mixed together.

Separate the concerns that change for different reasons

Separation pays off when a chunk of code mixes jobs that evolve independently — different reasons to change, different people, different speeds. Those seams are where bugs leak across and where tests get hard.

• Request handlers / controllers — split validation, business rules, storage, and response formatting instead of one fat handler.
• Anything touching the database — keep SQL behind a data-access layer so the rules above it never see a query string.
• UI apps — keep data, display, and control apart (this is exactly what MVC and its cousins do).
• Code you want to unit-test — if you can't test the rules without standing up real infrastructure, the rules and the infrastructure want separating.