Data Flow

Origin & evolution

The data-flow diagram came out of structured analysis in the 1970s. Larry Constantine is credited with the original idea, and the notation reached the mainstream through Tom DeMarco's 1978 book Structured Analysis and System Specification📋SpecificationFoundationsA canonical open standard or specification that primitives and products conform toView reference → and Edward Yourdon, with a parallel notation from Chris Gane and Trish Sarson. The diagram has four elements: external entities, processes, data stores, and the data flows between them. Its central move was to model a system by the data it moves and the transformations it applies, deferring the question of control sequence to a later stage.

That deferral marks the line that still matters: data flow versus control flow. A data-flow view shows what information goes where and how it is reshaped. A control-flow view, the territory of flowcharts and control-flow graphs, shows the order in which steps execute and which branch is taken. The same program has both, and structured analysis chose data flow first on the argument that the shape of the data outlasts the shape of the procedure.

Data-flow modelling found a durable second life in security. Microsoft's STRIDE threat☠️ThreatSecurityA specific security threatView reference →-modelling method begins by drawing a data-flow diagram and overlaying trust boundaries, the lines where data crosses a privilege level, because most threats live where data moves across such a boundary. The same flow view underpins data lineage🌳Data LineageData & AnalyticsA record of data origin and transformationsView reference →, where the question is which upstream source a given field came from and what touched it on the way.

How it works in practice

A team maps the data flow for a checkout. The shopper is the external entity; a flow carries a payment token from the browser, across a trust boundary, into the order service; a process validates it; a data store records the order; another flow forwards an anonymised event to analytics. Drawing it surfaces two findings a box diagram had hidden. The raw card token crosses into a logging sink that was never meant to hold payment data, a disclosure risk🎲RiskComplianceA risk to the product or businessView reference → the trust-boundary overlay makes obvious. And the analytics flow strips the customer ID, which silently breaks lineage: a later "which orders did this user place?" query cannot be answered from the warehouse. Both are properties of the flow, invisible until the flow is drawn.

Data flow vs. its neighbours

• Data lineage is the historical record of where a specific piece of data came from and how it was transformed. A data_lineage🌳Data LineageData & AnalyticsA record of data origin and transformationsView reference → is the audit trail; a data flow is the design of the pathways that produce it. Flow is the map; lineage is the recorded journey along it.

Kleppmann's treatment of data-intensive systems frames this distinction in architectural terms: in any system of meaningful scale, much of the data in play is *derived* — produced by a transformation applied to some upstream source — and the pipelines that perform those transformations are themselves a structural concern worth designing explicitly. By that reading, a data flow is not just a notation for what moves between boxes but a specification of the derivation chain: which source feeds which transformation, and what the output commits to. That framing makes the flow the natural place to reason about consistency guarantees and failure modes, since a broken or delayed link in the chain corrupts every downstream derivative.

• Domain entity📦Domain EntityEngineeringA DDD domain entity: a core object with a distinct identity and lifecycle inside a bounded contextView reference → is the structured thing that travels: an order, a payment, a user. A data flow data_flow_transports_domain_entityData FlowtransportsDomain Entitycausal, so the entity is the cargo and the flow is the route. The same entity can move along many flows.
• Bounded context🔲Bounded ContextEngineeringA DDD bounded context defining a service boundaryView reference → is a region of the model with its own language and rules. A bounded_context🔲Bounded ContextEngineeringA DDD bounded context defining a service boundaryView reference → is where data lives with shared meaning; a data flow is what crosses between contexts, which is exactly where translation and trust boundaries sit.

In the graph

In the Unified Product Graph, data_flow↕️Data FlowEngineeringA data flow between systems sits in the architecture region as a connective structure, a pathway through the system rather than an owned component. Products and contexts move through it via product_flows_through_data_flowProductflows throughData Flowhierarchy and bounded_context_flows_through_data_flowBounded Contextflows throughData Flowhierarchy; it carries structured payloads through data_flow_transports_domain_entityData FlowtransportsDomain Entitycausal; and concrete interfaces join it through api_endpoint_participates_in_data_flowAPI Endpointparticipates inData Flowsemantic. Modelling flow as first-class makes the cross-cutting questions answerable in one place: where a domain_entity📦Domain EntityEngineeringA DDD domain entity: a core object with a distinct identity and lifecycle inside a bounded contextView reference → travels, which api_endpoint🔌API EndpointEngineeringA specific API endpointView reference → touches it, and where a path crosses a context boundary and so deserves a closer look at security and lineage.