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 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.
• Domain entity📦Domain EntityEngineeringA DDD domain entityView 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 entityView 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.