Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Standalone conceptPrincipleChapter I · Principles · Building block 4 of 8

Single Responsibility Principle

A responsibility means a coherent ownership and its reasons for change, not one individual method.

By Michael Meierhoff · Meierhoff Systems

  1. ResponsibilityGroups behavior that changes for the same reason.
  2. Reason for changeExplains why a change becomes necessary for business or organizational reasons.
  3. CouplingChanges that happen together reveal where responsibilities are coupled.

Context

Why this is important

Group and separate responsibilities based on concrete reasons for change.

A design principle for business and technical module boundaries.

Shop example · Mapping

Responsibility and reason for change

The example shop remains a modular monolith with seven modules and a shared deployment.

This is how you read the picture

  1. Responsibility Responsibility
  2. Reason for change Trigger
  3. Coupling Change pattern
Responsibility and reason for change
ChangeObservationPossible responsibility
Business ruleRule changesBusiness module
PresentationFormat changesDocument component
Observed change patterns help assess responsibilities.

Benefits & limitations

Helps if:

  • A component must change for unrelated reasons.
  • Changes can be assigned to a coherent business or organisational responsibility.

Boundaries

  • “One class per method” increases the number of components and scatters related knowledge.
  • A clear reason for change is contextual; teams must test boundaries against real change patterns.

In practice

  1. Collect concrete changes from recent months and map them to the affected modules and classes. Check with the change team whether the cases share the same business or organizational reason.
  2. Group behavior that changes for the same reason and separate responsibilities with independent causes for change. Describe each responsibility as a coherent decision, not as a single method.
  3. Compare the proposed boundary with a concrete change case. If one requirement regularly makes several groups change together, check whether the model has divided rules or responsibilities poorly.
Read the detailed explanation

The Single Responsibility Principle is often explained as “one reason to change.” It helps align responsibilities with business or organisational reasons for change. A class may contain several methods when they serve one coherent task. Conversely, a single method can mix concerns when it handles business calculation, database access and formatting.

The principle examines reasons for change; Separation of Concerns frames concern separation, while Cohesion assesses how well a component holds together.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Which responsibility fits a change to shipping rules?

    View the solution with justification

    Business ownership of shipping.

  2. ApplyingTransferred to a new situation

    How do you check whether two tasks belong together?

    View the solution with justification

    Compare whether they arise from the same business reasons for change.

  3. EvaluateWeighing an alternative

    What is the effect of spreading one responsibility across many modules?

    View the solution with justification

    A business change requires coordinated updates in several places.

Explore further

These building blocks continue the thoughts of this page.

PrinciplesSeparation of ConcernsContext and comparisonOpening PrinciplesCohesionConceptual connectionOpening

References

Continue on the learning path

Next in Principles & boundaries: Module boundaries.

8 Building blocks

Continue withModule boundaries