Contents

Engineering Craft › Clean Code & Principles

Separation of Concerns

Each part of the program handles one distinct concern.

Also known as: SoC, separate concerns

Separation of concerns means each part of a program handles one distinct concern, and doesn’t mix in unrelated ones. A “concern” is a kind of job: displaying data, validating input, talking to a database, applying business rules.

# Mixed: one function does everything
def signup(request):
    email = request.form["email"]
    if "@" not in email: return "bad email"                      # validation
    db.execute("INSERT INTO users ...", email)                   # persistence
    smtp.send(email, "Welcome!")                                 # messaging
    return "<h1>Thanks!</h1>"                                    # presentation

# Separated
def signup(request):
    data = parse_signup(request)          # input handling
    user = users.register(data)           # business rules + persistence
    mailer.send_welcome(user)             # messaging
    return render_thanks(user)            # presentation

Why it matters

  • Change one thing at a time. Switch the database, restyle the page or replace the email provider without touching the rest.
  • Easier testing: test business rules without a web server or a database.
  • Understandable pieces: each file or module has a clear purpose.
  • Reuse: the same business logic can serve a web page, an API and a command-line tool.
  • Parallel work: different people work on different concerns.

Where you see it

  • Layers: presentation, business logic, data access (layered architecture).
  • MVC: model, view, controller (MVC).
  • Web basics: HTML for structure, CSS for style, JavaScript for behavior.
  • Services: auth, payments and notifications as separate components.

Cautions

  • Don’t over-split. A hundred tiny layers that just forward calls hurt readability.
  • Draw lines at real differences in why code changes, not by arbitrary technical categories (single responsibility, cohesion).
  • Keep dependencies pointing one way, such as business logic not depending on the web framework (coupling).