Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

PrincipleChapter I · Principles · Building block 3 of 6

Separation of responsibilities

Separation of responsibilities ranks tasks according to their different reasons for change; each responsibility is given a clear role and interface. English is called the Separation of Concerns, a term used by Edsger Dijkstra; at the class level, it is known as Single Responsibility, the S from SOLID.

By Michael Meierhoff · Meierhoff Systems

  1. FlowCoordinates the sequence of steps.
  2. Business rulesStatus and transitions of payment.
  3. ProtocolOnly the external API is known.

Context

Why this is important

When flow, business rules, and provider protocol are stuck in a building block, each change draws the others along. A new error code of the provider then touches the order process. Cohesion within a task is about cohesion.

This building block cuts across the board: business rule, flow and technology each get their own places. Whether the tasks belong together within a place clarifies cohesion.

At a glance · Every task with its own role

The workflow coordinates; business rules, protocol and storage change for different reasons and stay separate.
Shop example · Building blocks and relationships

Three Responsibilities of Payment

When making a payment, business status rules, the order process and the provider’s API change for various reasons. The shop separates these tasks into suitable building blocks.

This is how you read the picture

  1. Flow The box ordering process in the area of application.
  2. Business rules The box payment rules in the business domain.
  3. Protocol The box provider adapter in the field of technology that calls the payment provider.

Wide diagram · Move laterally if necessary

Each building block carries a task with its own reason for change.
Read diagram as text
  • Ordering process: Coordination of steps (Apply)
  • Payment rules: Status and transitions (Business domain)
  • Provider adapter: External protocol (Technique)
  • Payment provider: Authorisation API (External)
  • Ordering process → Payment rules: Starting payment
  • Payment rules → Provider adapter: Request authorisation
  • Provider adapter → Payment provider: Call for APIs
  • Provider adapter → Payment rules: Translating results
Each building block carries a task with its own reason for change.

Three directions of separation

Three directions of separation
DirectionWhat is SeparatedIn the shopDeepened in
VerticalBusiness areasCatalogue, payment, shippingCohesion, module boundaries
Horizontalflow, business rule, technologyOrder process, payment rules, provider adapterThis building block, layered architecture, hexagonal architecture
Cross sectionConcerns that are needed everywhereLogging, Authorization, Error TreatmentObservability, authentication & authorization, gateway
Vertically and horizontally, tasks can be distributed on own building blocks. Cross-cutting topics are needed everywhere and therefore need their own mechanisms instead of their own module.

Benefits & limitations

Helps if:

  • Changes to presentation or infrastructure repeatedly damage business rules.
  • A task must be independently tested or reused on multiple input paths.

Boundaries

  • Layers without a distinct purpose increase coordination and search effort. Assess their responsibilities through Cohesion and concrete change paths.
  • Transactions and failures may affect several concerns at once. Identify the coordinating flow and examine its Module Boundaries so these relationships remain visible.

In practice

  1. Include reasons for change. Separate business rules, technical connection and presentation based on their respective change patterns. The result shows which tasks can be handled independently.
  2. Assign responsibilities and contracts. Determine which part accepts input, makes decisions and performs technical effects. Use Module Boundaries to define binding handover contracts.
  3. Test collaboration and failure paths. Check individual responsibilities and the complete flow, including failures. Cohesion helps assess whether related rules remain together.
Read the detailed explanation

A system flow can combine input handling, business decisions, storage and presentation. These concerns can be handled separately at clear boundaries while keeping the overall process understandable. Cohesion groups related tasks; Dependency Inversion keeps the business core independent of infrastructure.

Separation helps when responsibilities change or are tested independently. It still requires explicit coordination for transactions, permissions and failure paths that cross several parts. A layer should have its own responsibility, such as translation, rule checking or flow control; passive pass-through layers add overhead. Assess boundaries against the changes and collaboration required by a complete flow.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Which building block calls the payment provider’s API?

    View the solution with justification

    The provider adapter, via the edge “call API” to the payment provider.

  2. ApplyingTransferred to a new situation

    All access to order, payment and shipping should be logged. What direction of separation is this, and where does it belong?

    View the solution with justification

    A cross-cutting issue. It does not belong in each module individually, but in a common mechanism, such as middleware or a gateway, so that the specialist modules remain free of it.

  3. EvaluateWeighing an alternative

    The team is considering merging payment rules and provider adapters. What speaks for and against?

    View the solution with justification

    For this: a building block fewer and shorter paths. On the other hand, the technical status and the provider protocol have different reasons for change, and a change of provider would affect the rules.

Explore further

These building blocks continue the thoughts of this page.

PrinciplesCohesionCohesion groups tasks that belong to a shared responsibility within one building block.Opening PrinciplesDependency InversionDependency Inversion aligns the domain core with stable contracts instead of concrete technical tools.Opening DomainAnti-Corruption LayerAn Anti-Corruption Layer translates foreign data and terms into the domain model.Opening PrinciplesModule boundariesModule boundaries define which data and capabilities a module owns and which contracts others use to access them.Opening

References

Continue on the learning path

Next in Principles & boundaries: Module boundaries.

6 Building blocks

Continue withModule boundaries