One JSON Message, Two Flows: Separating Data from Control in System Modeling

Core Insight: One Message, Two Flow Types

A single JSON payload can simultaneously contain fields that belong to the data flow (business entities) and fields that belong to the control flow (commands, parameters, status codes). The classification depends on the semantic purpose of each field, not on the transport format.

Real-World Payment Message Example

The request sent from a client to a payment gateway illustrates the split:

{ "action": "create_payment", "timeout": 300, "order_no": "ORD20261012001", "user_id": "U10086", "amount": 99.00, "goods_name": "技术书籍" }

action and timeout are control data — they instruct the gateway what to do and how to behave.

order_no , user_id , amount , goods_name are business data — they represent the order, user, amount, and product.

The response follows the same pattern: code (success/failure) is control data; order_no and pay_time are business data.

Key Principle: Purpose Over Carrier

Whether the payload is JSON, text, or binary does not determine the flow type. The same message can carry both types, so modeling requires separating them.

Definitions

Data Flow : Carries business or domain entity content — the raw materials, work-in-progress, and outputs that the system processes to complete business tasks.

Control Flow : Carries scheduling, coordination, and management signals that decide whether, when, and which action a module executes. It does not carry business entity information.

In short: Data flow is what the system processes; control flow is the command that tells the system how to work.

Standard DFD Elements and Common Mistakes

A Data Flow Diagram (DFD) describes where business data comes from, where it goes, and which processes transform it. It does not capture execution sequence, branching, or invocation commands. Standard DFD elements are: external entities, processes, data stores, and data flows.

Three frequent errors:

Processes must describe data operations, not system names. "Payment Gateway" is a system; "Create Payment Order" or "Query Payment Result" describes a single data operation.

Data flows must distinguish read from write. The same "Payment Record" written and read are two distinct flows and both must appear.

Return flows must not be omitted. Data that goes out must have a result coming back; a one-way diagram is incomplete.

DFD Example for Payment Gateway

The level-0 DFD shows two processes corresponding to the most common data operations: Create (write) and Query (read) . Control fields such as action, timeout, and success do not appear on the DFD — they belong to control flow and require other diagrams.

Control Flow Diagrams: Sequence, Activity, State Machine

Three UML diagrams address different control-flow concerns:

Sequence Diagram : Shows time-ordered control messages and responses between components — ideal for call/return interactions.

Activity Diagram : Captures execution steps, branching logic, and loops — focuses on process flow (if condition A then branch 1 else branch 2).

State Machine Diagram : Depicts how an object transitions between states under external control signals.

Mapping to the Payment Example

Client calls gateway, sends create command, gateway returns success/failure → Sequence Diagram

Validate parameters → initiate payment → judge result → on success write record, on failure return error → Activity Diagram

Payment order status transitions: Pending → Processing → Success / Failure → State Machine Diagram

DFD is not used for control flow. It only describes business data sources, transformations, storage, and destinations.

Summary: Data Flow vs. Control Flow

Business Data (Data Flow) : order_no, user_id, amount, goods_name, pay_time, transaction records. Purpose: business entity information, object of system processing. DFD: drawn. Diagram: DFD.

Control Data (Control Flow) : action command, timeout, success/error codes, start/stop signals, branch conditions, retry commands. Purpose: scheduling and directing component execution. DFD: not drawn. Diagrams: Sequence, Activity, State Machine.

Conclusion

Modeling starts with classifying each piece of information by its purpose. Once separated, business data naturally fits into DFDs, while control data finds its place in sequence, activity, or state machine diagrams. Mixing them leads to incomplete or misleading models.

References: DeMarco (1978) Structured Analysis and System Specification ; Gane & Sarson (1979) Structured Systems Analysis: Tools and Techniques ; OMG Unified Modeling Language (UML) Specification .