Skip to content
Software Architecture Guide

Context View Antipattern: Forgetting Bidirectional Data Flows

Explanation

Section titled “Explanation”

A context diagram shows your system as a black box surrounded by users and external systems. For background, see the articles “Context View” and “Business and Technical Context”.

The antipattern. The diagram draws a single arrow between the system and a neighbor, although data moves in both directions. The reader sees only half of the exchange.

Why arrows cause trouble. An arrow can mean data flow, the side that starts a call, or a dependency. Many people read an arrow between systems as data flow. Directed UML relationships such as dependency or association can confuse non-technical readers. So arc42 advises showing data flows, not dependencies, in the business context.

What gets hidden. Section 3 of arc42 wants all stakeholders to understand which data the system exchanges with its environment. A one-way arrow drops one half of that exchange. Nobody sees what the neighbor sends back, so nobody plans for it. Domain and technical interfaces to communication partners are among the most critical aspects of a system. Missing flows weaken exactly those interfaces.

Business and technical context. The business context shows what data is exchanged. The technical context shows the channels and transmission media that link the system to its environment. arc42 advises relating each domain interface to its technical realization. Check both views for flows in both directions.

How to draw it. Azure guidance offers two options for two-way communication:

  • Show two separate arrows, one per direction. This is the preferred option.
  • Annotate a single arrow with request and response notes.

Label lines when their meaning is not obvious, and add a legend if you introduce line semantics. Name the data in each direction.

The same guidance warns against double-headed arrows. They imply bidirectional dependencies, and it suggests arrows from the initiating component to the dependency. That convention differs from data-flow meaning. Pick one meaning for arrows and state it.

Keep detail low. arc42 asks you to document all external neighbors, but grouping them is fine.

Example

Section titled “Example”

An online shop draws one arrow from “Shop” to “Payment Service”, labeled “payment request”. The diagram looks complete.

In reality, the payment service also returns a result: approved, declined or failed. The shop must handle each outcome. Because the diagram shows no return flow, no one specified that result, and no one planned what happens when it fails or never arrives.

The fix is a second arrow back to the shop, labeled “payment result”. Now the interface has two documented data flows, and each can be specified and reviewed.

Trade-offs

Section titled “Trade-offs”

Two arrows per neighbor make a diagram busier. With many neighbors, the picture gets crowded. One annotated arrow is more compact but easier to overlook. arc42 allows grouping neighbors to keep the view readable.

Double-headed arrows look tidy but can wrongly suggest two-way dependencies. Whichever notation you choose, state what arrows mean in a legend.

Two labeled flows show both directions of the exchange with an external payment service.

Diagram source 
flowchart LR
  S[Shop system] -->|payment request| P[Payment service]
  P -->|payment result| S

Checks

Section titled “Checks”
  • Every external neighbor with two-way exchange shows both directions, as two arrows or one annotated arrow.
  • Each flow is labeled with the data exchanged, and a legend states what arrows mean.
  • The business context shows data flows, not dependencies.
  • Each domain interface is linked to its technical channel in the technical context.
  • All external neighbors appear, individually or as a documented group.
Section titled “Related”

Sources

Section titled “Sources”