data-flow-model

Extract core entities from the requirement text using noun extraction, operation inference, or event sourcing, then define relationships with cardinality in a mermaid erDiagram. List only key fields with PK, FK, required, and unique constraints rather than every column.

Use a mermaid flowchart where nodes represent entities, components, users, or external systems, and edges show data direction with trigger conditions. Annotate each flow with CRUD operations (Create, Read, Update, Delete) to describe how data changes as it moves.

Concurrent scenario analysis must define transaction boundaries, lock strategy (optimistic vs pessimistic), isolation level, and conflict handling for each operation. For example, inventory deduction might use optimistic locking with version numbers and retry on conflict.

Data modeling happens after requirement mining, interaction design, and work breakdown, but before technical design. It clarifies what the data looks like and how it flows so the technical design phase can reference the ER diagram and flow definitions directly.

It deliberately avoids implementation decisions like database or message queue selection, covering only data structure and flow direction. Detailed field lists and physical schema design are deferred to the technical design phase.