System context & system boundary
A system context shows the considered system as a unit and identifies its external actors. Internal building blocks remain hidden at this level.
- SystemA unity whose interior remains hidden.
- ActorsPersons and systems outside the border.
- RelationshipsWhat flows between the shop and the outside world.
Context
Why this is important
Without a system boundary, it remains unclear what the shop itself stands for and where dependencies to others begin. Then interfaces to payment providers or transport partners are overlooked. The internal division shows other building blocks.
This building block explains external relations and system boundary. For internal modules, see Software Architecture and Module Boundaries.
At a glance · System as a black box in the environment
System context of the shop
The shop accepts orders from customers and exchanges information with payment providers, shipping service providers and warehouse team. The internal shipping module prepares deliveries; the external transport partner transports them. The warehouse team also maintains the floor from the outside, while the warehouse module in the shop manages the reservations. All internal shop modules are within a single system boundary.
This is how you read the picture
- System The box shop in the system area – without internal modules.
- Actors The customer, payment provider, shipping service provider and warehouse team boxes in the external area.
- Relationships The arrow labels ordered, request payment, register shipment and maintain stock.
Wide diagram · Move laterally if necessary
Read diagram as text
- Customer: Buying Products (External)
- Shop: Order processing (System)
- Payment provider: Authorize payment (External)
- Shipping provider: Consignment transported (External)
- Warehouse team: Providing goods (External)
- Customer → Shop: Ordered
- Shop → Payment provider: Payment request
- Shop → Shipping provider: Notification of consignment
- Warehouse team → Shop: Maintaining stock
Benefits & limitations
Helps if:
- A new initiative needs a shared definition of delivery scope and external dependencies.
- Stakeholders use the same system name for different areas of responsibility and need to clarify the scope.
Boundaries
- The system context does not show the shop's internal decomposition; that requires an Architecture View showing its building blocks.
- An arrow to the payment provider establishes neither availability nor a data format; those commitments belong in the API Contract.
- The boundary depends on the system being considered: what is external to the shop is internal to the provider's own system.
In practice
- Define the system and its purpose. State which business capability is being considered and which tasks fall within the system's responsibility. This provides a clear frame of reference for the context view.
- Identify actors and external partners. Record the roles and systems that supply input, use results or influence the process. Distinguish them from internal building blocks; Architecture Views can then explain the internal structure.
- Label the direction of each interaction. State its trigger, business content and response. Refer to the API Contract for technical commitments so the context map keeps protocol details separate from business responsibilities.
Read the detailed explanation
The context view identifies the system under consideration, its users and the external systems it works with to fulfil business responsibilities. The boundary encloses the system's own responsibilities. Elements outside it may be important to a business process but remain someone else's responsibility.
The direction and business purpose make each relationship understandable: who requests which capability, who supplies information, and what result is returned? Internal decomposition is described in a separate architecture view. Module Boundaries addresses internal responsibilities; Bounded Context explains the business meaning of different models.
Simon Brown's C4 system context diagram is a common form of this view: a system in the centre, surrounded by users and neighbouring systems.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which actor reports the stock to the shop according to the presentation?
View the solution with justification
The warehouse team. The edge “Keep stock” leads from the warehouse team to the shop; the warehouse team is located in the External Zone.
ApplyingTransferred to a new situation
In future, the shop will send order confirmations via an external mail provider. What changes in the system context?
View the solution with justification
The mail provider would be added as another external node with an edge from the shop. The internal modules remain invisible, because only the external relationship counts.
EvaluateWeighing an alternative
The team wants to show the seven modules additionally in the system context. What disadvantage does that have?
View the solution with justification
The advantage is more detail. The disadvantage: The boundary between inside and outside is blurred, and the picture no longer answers the question of who the shop is talking to. Internal modules belong in their own view.
Explore further
These building blocks continue the thoughts of this page.
References
- arc42 · Contextual delimitation (opens in new tab)Make system boundary, user and external interfaces visible.
- C4 · System Context (opens in new tab)Shows system, users and neighboring systems on an understandable overview.
- DDD Crew · Bounded Context Canvas (opens in new tab)Working template for the purpose, language and interactions of a bound context.