Data Flow Diagram: Order System

A data flow diagram (DFD) shows where data comes from, which processes transform it, where it is stored and where it leaves the system. This sample models a small online shop: a customer places an order, the system validates it, takes payment, ships it and emails a confirmation.

DFDs are not UML. UML covers software structure and behaviour; DFDs are one of the other standard notations used alongside it. This page uses Gane-Sarson symbols and shows both a level 1 diagram and the level 0 context diagram it refines.

1. The Diagram: Level 1 DFD

Read it by following the data, not the clock. A DFD has no sequence; it only says which data can reach which process.

Customer (an external entity, outside our control) sends order details into process 1.0 Validate Order.
1.0 reads the customer record from data store D1 Customers, writes a new order into D2 Orders and passes a valid order on to 2.0.
2.0 Take Payment exchanges a charge request and an auth result with the Payment Gateway, then records the paid status in D2.
3.0 Fulfil Order reads the order to ship from D2, sends a pick list to the Warehouse, receives a tracking number, and decrements stock in D3 Inventory.
3.0 emits a shipped event to 4.0 Notify Customer, which sends the confirmation back out to the Customer.

Notice that processes never talk to stores of another system directly, and stores never talk to each other: every flow passes through a process. That rule is the first thing a reviewer checks.

2. How to Read It

Gane-Sarson uses rounded rectangles for processes (with the number in a top band), open-ended rectangles for stores and shaded squares for external entities. The older Yourdon-DeMarco style draws processes as circles and stores as two parallel lines; the meaning is identical. Label flows with nouns ("pick list"), and processes with verb-object phrases ("Fulfil Order").

3. Variant: Level 0 Context Diagram

The context diagram is the same system zoomed out: one process numbered 0 and every flow that crosses the boundary. It is the best first conversation with stakeholders, because it fixes the scope. A key check when you decompose it: the level 1 diagram must have exactly the same external flows (order details, confirmation, charge request and so on). This is called balancing. If level 1 shows a new flow to an outside party, either the context diagram or the decomposition is wrong.

4. Pros, Cons, and When to Use

Pros

Shows data movement and storage in one picture, ideal for privacy and compliance reviews (where does PII go?).
Very few symbols; business users read it after a two-minute introduction.
Levelled decomposition scales from a context view down to detailed processes.
Each flow becomes a candidate interface, table or API payload.
Natural input for threat modelling (STRIDE works on DFD elements and trust boundaries).

Cons

No timing, ordering or concurrency: you cannot see what happens first.
Says nothing about technology (queues, databases, batch vs streaming).
Large levels become spaghetti; keep each level to roughly 5-9 processes.
Balancing across levels is manual and drifts as the system changes.
Unfamiliar to many developers trained only on UML.

When to use

Scoping a new system or integration.
Data protection and GDPR data maps.
Threat modelling sessions.

When not to use

Showing the order of tasks (use a pipeline DAG or sequence diagram).
Describing runtime infrastructure (use a topology or deployment diagram).

5. As Diagrams-as-Code

Graphviz has no native DFD shapes, but rounded boxes and record nodes give a close match:

// Graphviz DOT - level 1 DFD (render: dot -Tsvg dfd.dot)
digraph dfd1 {
  rankdir=LR; node [fontname="Helvetica"];
  Customer [shape=box, style=filled, fillcolor="#ffe9a8"];
  Gateway  [label="Payment Gateway", shape=box, style=filled, fillcolor="#ffe9a8"];
  Warehouse[shape=box, style=filled, fillcolor="#ffe9a8"];
  P1 [label="1.0\nValidate Order", shape=box, style=rounded];
  P2 [label="2.0\nTake Payment",   shape=box, style=rounded];
  P3 [label="3.0\nFulfil Order",   shape=box, style=rounded];
  P4 [label="4.0\nNotify Customer",shape=box, style=rounded];
  D1 [label="D1 | Customers", shape=record];
  D2 [label="D2 | Orders",    shape=record];
  D3 [label="D3 | Inventory", shape=record];
  Customer -> P1 [label="order details"];
  D1 -> P1 [label="customer record"];
  P1 -> P2 [label="valid order"];   P1 -> D2 [label="new order"];
  P2 -> Gateway [label="charge request"]; Gateway -> P2 [label="auth result"];
  P2 -> D2 [label="paid status"];   D2 -> P3 [label="order to ship"];
  P3 -> Warehouse [label="pick list"]; Warehouse -> P3 [label="tracking no."];
  P3 -> D3 [label="stock decrement"]; P3 -> P4 [label="shipped event"];
  P4 -> Customer [label="confirmation"];
}

Data Flow Diagrams — notation reference
Context Diagrams — level 0 in depth
Data Dictionary — defining each flow and store
ETL Pipeline — how these flows become batch jobs
Pipeline DAG Diagram — sibling sample
Data Lineage Graph — sibling sample
Lambda vs Kappa Diagram — sibling sample
Streaming Topology Diagram — sibling sample
Medallion Lakehouse Diagram — sibling sample
Data Engineering diagrams — section overview