Architecture process · Station 2 of 8

System boundaries & responsibilities

One of eight stations in the architecture work cycle, shown on the example shop.

02Stage 2 of 8 · Boundaries

What are the responsibilities?

Here you set the viewing frame and assign tasks, data and interfaces to those responsible.

You need

Prioritised goals and constraints
Domain terms from the workflows

Who

Payment module owner leads

with Product owner, Platform team

How to proceed

1
Describe system context and external stakeholders.
2
Clear business boundaries and responsibility for data.
3
Sketch contracts between the responsible parts.

In the shop

System boundary and modules of the shop

System boundary: All shop modules sit inside one boundary; payment provider and shipping carrier sit outside.
Contexts: Order and invoice use “amount” and “status” differently.
Data ownership: The stock module owns inventory; the order module does not change the stock table directly.
Relationship: The payment provider sets its own model; the shop translates.

This creates

Contextual view
Technical limits
Responsibilities for data

Tools for this:Bounded Context Context Map Event Storming All under “Shape boundaries” →

Done when

The system context names all external stakeholders.
Every table has exactly one owning module.
Interfaces between modules are sketched as contracts.

Appropriate Building Blocks

Domain · ConceptBounded ContextA bounded context defines where a domain model and its terms apply.Data · ConceptData ownershipData ownership defines which building block is responsible for data and its domain rules.Domain · ArtifactContext MapThe Context Map shows how domain contexts work together and depend on one another.Fundamentals · ConceptSystem context & system boundaryHere you see where your system takes responsibility and how it works with users and neighboring systems.Principles · ConceptModule boundariesModule boundaries define which data and capabilities a module owns and which contracts others use to access them.