DFD простыми словами: как данные движутся внутри системы

Когда проектируют информационную систему, недостаточно знать только бизнес-процесс, структуру базы данных или набор сервисов.

Нужно понимать ещё одну вещь:

Какие данные входят в систему, кто их создаёт, куда они передаются, где хранятся и кто их использует дальше?

Например, абитуриент отправляет заявку в CRM.

С точки зрения бизнес-процесса нас может интересовать:

Подать заявку -> Проверить -> Согласовать

С точки зрения базы данных:

Student 1:N Application N:1 Program

А с точки зрения движения информации:

Applicant -> Application data -> CRM -> Application record -> PostgreSQL

Именно последний вопрос описывает DFD - Data Flow Diagram.

DFD показывает не последовательность действий во времени, а движение данных между участниками, процессами и хранилищами.

Что такое DFD

DFD расшифровывается как Data Flow Diagram.

В основе диаграммы четыре элемента:

External Entity - внешний источник или получатель данных
Process - преобразование данных
Data Store - место хранения данных
Data Flow - передаваемые данные

Простейшую модель можно представить так:

Applicant -> Application data -> Application Processing -> Application record -> Applications Store

Здесь видно:

• кто передаёт данные;
• какие именно данные передаются;
• какой процесс их обрабатывает;
• что сохраняется после обработки.

DFD отвечает прежде всего на вопрос:

Куда движется информация и что происходит с ней по пути?

External Entity

External Entity - объект за границей рассматриваемой системы, который отправляет или получает данные.

Например:

Applicant
Manager
Payment Provider
Education Platform
Email Provider
Government Registry

External Entity не обязательно является человеком.

Это может быть:

• пользователь;
• организация;
• внешняя информационная система;
• API другого сервиса;
• платёжный провайдер;
• государственная система.

Главный критерий:

Рассматриваем ли мы этот объект как часть моделируемой системы?

Если проектируется CRM, то Applicant является внешней сущностью.

Если проектируется вся цифровая экосистема образовательной платформы, та же CRM может сама оказаться одним из внутренних компонентов.

Поэтому граница DFD зависит от выбранного масштаба модели.

Process

Process - преобразование входных данных в выходные.

Например:

Register Application
Verify Documents
Calculate Payment
Generate Report
Send Notification

Процесс должен что-то делать с данными.

Плохое название:

Application

Непонятно, что происходит.

Лучше:

Process Application
Validate Application
Create Application

Это связано с важным правилом DFD:

External Entity - обычно существительное
Data Store - обычно существительное
Data Flow - название данных
Process - действие

Например:

Applicant -> Application data -> Validate Application

После процесса данные должны измениться, быть проверены, объединены, преобразованы или использованы для получения нового результата.

Если процесс получает данные и отдаёт абсолютно те же данные без какого-либо смысла, стоит проверить, нужен ли он вообще на диаграмме.

Data Flow

Data Flow - данные, передаваемые между элементами DFD.

Поток изображается стрелкой.

Но стрелка сама по себе почти ничего не говорит.

Плохо:

Applicant -> CRM

Непонятно, что именно передаётся.

Лучше:

Applicant -> Application data -> Application Processing

Другой пример:

Application Processing -> Application status -> Applicant

Название потока должно описывать содержимое информации, а не действие.

Хорошо:

Application data
Payment details
Verification result
Document metadata
Notification data
Report parameters

Плохо:

Send
Process
Check
Request

Поток данных отвечает на вопрос:

Что передаётся?

Data Store

Data Store - место, где данные сохраняются между операциями.

Например:

Applications
Documents
Users
Payments
Audit Log

На логической DFD обычно не обязательно писать:

PostgreSQL
Redis
S3

если нас интересует прежде всего смысл хранимых данных.

В таком случае лучше:

Application Store
Document Store
User Store

Это важное различие между логической и физической DFD.

Логическая DFD показывает:

что хранится

Физическая DFD может показывать:

где именно хранится

Например:

Application Store -> PostgreSQL
Document Store -> MinIO
Session Store -> Redis

Не стоит смешивать эти уровни без необходимости.

Основные правила соединения элементов

DFD имеет простые, но важные ограничения.

Допустимо:

External Entity -> Process
Process -> External Entity
Process -> Data Store
Data Store -> Process
Process -> Process

Например:

Applicant -> Application data -> Submit Application
Submit Application -> Application record -> Applications Store
Applications Store -> Application record -> Review Application
Review Application -> Review result -> Manager

Некоторые прямые связи обычно не имеют смысла.

External Entity -> Data Store

Плохо:

Applicant -> Applications Database

Если пользователь пишет данные в базу через систему, между ними должен существовать процесс:

Applicant -> Application data -> Submit Application -> Application record -> Applications Store

Иначе DFD пропускает саму обработку.

Data Store -> Data Store

Плохо:

Applications Store -> Archive Store

Данные не должны самостоятельно перемещаться между хранилищами.

Нужен процесс:

Applications Store -> Archived application -> Archive Application -> Archive record -> Archive Store

External Entity -> External Entity

Если два внешних участника взаимодействуют напрямую и система в этом не участвует, такое взаимодействие обычно находится за пределами DFD рассматриваемой системы.

Если взаимодействие проходит через систему:

Applicant -> Request -> CRM Process -> Notification -> Manager

тогда его уже имеет смысл показывать.

Пример простой DFD

Представим CRM образовательной программы.

Абитуриент подаёт заявку.

Система сохраняет её.

Оператор позже получает данные заявки и проверяет их.

После проверки статус заявки изменяется.

На DFD это можно представить так:

Applicant -> Application data -> Submit Application -> Application record -> Applications Store
Applications Store -> Application data -> Review Application
Manager -> Review decision -> Review Application
Review Application -> Updated application -> Applications Store
Review Application -> Application status -> Applicant

Здесь уже видно несколько важных вещей:

• Applicant создаёт данные заявки;
• процесс Submit Application принимает их;
• данные сохраняются;
• Review Application читает их из хранилища;
• Manager передаёт решение;
• изменённое состояние снова сохраняется;
• Applicant получает результат.

DFD позволяет увидеть информационные зависимости без погружения в HTTP, SQL или реализацию frontend.

Context Diagram

Начинать большую DFD удобнее не с внутренних процессов, а с Context Diagram.

На Context Diagram вся рассматриваемая система представляется одним процессом.

Например:

Applicant -> Application data -> CRM System
CRM System -> Application status -> Applicant

Manager -> Review decision -> CRM System
CRM System -> Application data -> Manager

CRM System -> Payment request -> Payment Provider
Payment Provider -> Payment result -> CRM System

CRM System -> Enrollment data -> Education Platform
Education Platform -> Enrollment result -> CRM System

Внутренние детали CRM пока не показываются.

То есть отсутствуют:

Application Management
Document Management
Notifications
PostgreSQL
RabbitMQ
Celery

На этом уровне нас интересует только граница:

внешний мир -> CRM System -> внешний мир

Context Diagram позволяет быстро ответить на вопросы:

• кто взаимодействует с системой;
• какие данные входят;
• какие данные выходят;
• какие внешние интеграции существуют;
• где проходит граница ответственности системы.

Зачем начинать с Context Diagram

Если сразу строить подробную схему, легко потерять границы системы.

Например, на одной диаграмме появляются:

Applicant
React
Django
PostgreSQL
Redis
RabbitMQ
Celery
MinIO
Payment Provider
Email Provider
Manager

И уже непонятно, что именно анализируется.

Context Diagram заставляет сначала определить:

что находится внутри системы

и:

что находится снаружи

Это особенно полезно перед проектированием интеграций и API.

Level 0

После Context Diagram система декомпозируется.

Допустим, на верхнем уровне был один процесс:

CRM System

На Level 0 его можно разбить на несколько крупных процессов:

1.0 Manage Applications
2.0 Manage Documents
3.0 Send Notifications
4.0 Generate Reports

И добавить хранилища:

D1 Applications
D2 Documents
D3 Users

Теперь схема становится подробнее.

Например:

Applicant -> Application data -> 1.0 Manage Applications
1.0 Manage Applications -> Application record -> D1 Applications
D1 Applications -> Application data -> 4.0 Generate Reports
2.0 Manage Documents -> Document metadata -> D2 Documents
3.0 Send Notifications -> Notification -> Applicant

Level 0 показывает основные функции системы и движение данных между ними.

Level 1

Любой крупный процесс Level 0 можно декомпозировать дальше.

Например:

1.0 Manage Applications

раскладывается на:

1.1 Receive Application
1.2 Validate Application
1.3 Store Application
1.4 Review Application
1.5 Update Application Status

Теперь поток можно показать подробнее:

Applicant -> Application data -> 1.1 Receive Application -> Raw application -> 1.2 Validate Application
1.2 Validate Application -> Valid application -> 1.3 Store Application -> Application record -> D1 Applications
D1 Applications -> Application data -> 1.4 Review Application
Manager -> Review decision -> 1.4 Review Application -> Review result -> 1.5 Update Application Status
1.5 Update Application Status -> Updated application -> D1 Applications

Так одна крупная функция постепенно раскрывается без превращения всей DFD в огромную схему.

Нумерация процессов

При декомпозиции обычно используется иерархическая нумерация.

Например:

1.0 Manage Applications
2.0 Manage Documents
3.0 Send Notifications

Декомпозиция процесса 1.0:

1.1 Receive Application
1.2 Validate Application
1.3 Store Application
1.4 Review Application

Декомпозиция процесса 2.0:

2.1 Upload Document
2.2 Validate Document
2.3 Store Document

Нумерация помогает понять, к какому родительскому процессу относится более подробная схема.

Баланс между уровнями

Одно из важнейших правил декомпозиции DFD - balancing.

Внешние входы и выходы процесса на верхнем уровне должны сохраняться при его раскрытии на следующем уровне.

Представим Level 0:

Applicant -> Application data -> 1.0 Manage Applications
1.0 Manage Applications -> Application status -> Applicant

На Level 1 процесс 1.0 раскрывается.

Там должен сохраниться вход:

Application data

и выход:

Application status

Например:

Applicant -> Application data -> 1.1 Receive Application -> 1.2 Validate Application -> 1.3 Store Application
1.3 Store Application -> Application status -> Applicant

Нельзя внезапно добавить на дочернем уровне новый внешний поток:

Applicant -> Passport Scan

если на родительском уровне никакого такого потока не существовало.

И наоборот, нельзя потерять вход или выход верхнего уровня.

Именно это называется балансом между уровнями.

Почему balance важен

Без balancing разные уровни начинают описывать разные системы.

Например, Context Diagram говорит:

Payment Provider -> Payment result -> CRM

а после декомпозиции никакой Payment result больше нигде не существует.

Возникает вопрос:

Куда исчезли данные?

Или наоборот, на Level 1 внезапно появляется:

Tax Service -> Tax data -> Calculate Payment

хотя на Context Diagram такой интеграции не было.

Это значит, что верхний уровень уже не отражает реальные границы системы и должен быть обновлён.

Какой уровень детализации нужен

Нет смысла бесконечно раскладывать процессы.

Например:

Validate Application

можно разложить:

Validate required fields
Validate email
Validate program
Validate documents

А потом ещё глубже:

Parse email
Compare regex
Check domain

Но DFD быстро превратится в описание программного алгоритма.

Остановиться стоит тогда, когда текущий уровень уже отвечает на аналитический вопрос.

Для бизнес-анализа может хватить:

Validate Application

Для проектирования интеграции может понадобиться:

Validate Application -> Validate Program -> Verify Documents

Для описания конкретного Python-кода DFD обычно уже не лучший инструмент.

Логическая и физическая DFD

Это различие полезно фиксировать отдельно.

Логическая DFD

Показывает, что делает система и какие данные движутся.

Например:

Applicant -> Application data -> Process Application -> Application Store

Здесь нет:

React
Django
PostgreSQL
HTTP
JSON

Это модель предметной логики.

Физическая DFD

Показывает, какими конкретными технологиями реализовано движение данных.

Например:

React -> JSON application payload -> Django REST API -> SQL INSERT -> PostgreSQL

или:

Django -> Notification message -> RabbitMQ -> Celery Worker -> Email Provider

Физическая модель ближе к архитектуре реализации.

Главное - не смешивать оба уровня случайным образом.

Плохо:

Applicant -> Django -> Application Store -> RabbitMQ -> Проверить заявку

Здесь одновременно находятся:

• пользователь;
• framework;
• логическое хранилище;
• инфраструктура;
• бизнес-действие.

Сначала нужно определить цель схемы.

DFD и безопасность

DFD особенно полезна для security analysis, потому что она показывает, где именно движутся чувствительные данные.

Например:

Applicant -> Personal data -> CRM
CRM -> Payment data -> Payment Provider
CRM -> Student data -> Education Platform

Теперь можно определить типы информации:

Personal data
Credentials
Payment data
Documents
Access tokens
Internal identifiers

После этого можно анализировать каждый поток отдельно.

Например:

Applicant -> Personal data -> CRM

возникают вопросы:

• передаются ли данные по защищённому соединению;
• какие поля действительно нужны;
• где данные сохраняются;
• кто получает к ним доступ;
• сколько времени они хранятся.

Trust Boundaries

При threat modeling поверх DFD часто добавляют trust boundaries.

Trust Boundary показывает переход между областями с разным уровнем доверия.

Например:

Internet | Trust Boundary | Backend Network

или:

CRM | Trust Boundary | External Payment Provider

Поток:

Browser -> Access token -> Backend

пересекает границу доверия.

Такой переход требует отдельного анализа.

Например:

• authentication;
• authorization;
• encryption;
• input validation;
• rate limiting;
• logging;
• secret management.

Важно понимать, что trust boundary не является одним из четырёх базовых элементов классической DFD. Это дополнительный слой, который часто используется при threat modeling.

DFD как основа threat modeling

Представим поток:

Applicant -> Passport data -> Upload Document -> Document Store

Теперь можно последовательно проверить:

External Entity -> Data Flow -> Process -> Data Store

На каждом участке возникают свои угрозы.

Для External Entity:

кто отправляет данные?
как проверяется пользователь?

Для Data Flow:

защищён ли канал?
можно ли изменить данные по дороге?

Для Process:

валидируется ли вход?
можно ли загрузить вредоносный файл?

Для Data Store:

кто имеет доступ?
шифруются ли данные?
есть ли retention policy?

Поэтому DFD используется как удобная исходная карта системы для threat modeling.

DFD и API

DFD показывает:

что передаётся

API contract показывает:

как именно это передаётся

Например, DFD:

Applicant -> Application data -> CRM

На уровне API это может превратиться в:

POST /applications

{
  "program_id": 42,
  "first_name": "Sergey",
  "last_name": "Kitov"
}

DFD не должна содержать полный JSON schema.

Её задача выше уровнем:

Application data

А OpenAPI уже описывает:

• HTTP method;
• URL;
• headers;
• request body;
• field types;
• validation;
• response;
• error codes.

Поэтому связь выглядит так:

DFD Data Flow -> API operation -> OpenAPI contract

Один Data Flow не всегда равен одному HTTP request

Это тоже важно.

Например, на DFD существует:

CRM -> Student data -> Education Platform

Технически это может быть реализовано через:

REST API

или:

Webhook

или:

RabbitMQ

или:

Kafka

или:

SFTP file exchange

DFD намеренно не привязывает смысловой поток данных к конкретному транспорту, если строится логическая модель.

Поэтому сначала можно определить:

какие данные должны двигаться

а затем:

каким способом их передавать

DFD и BPMN

BPMN и DFD часто моделируют одну предметную область, но смотрят на неё по-разному.

Представим процесс:

Подать заявку -> Проверить -> Согласовать

BPMN показывает:

порядок действий

DFD для того же сценария показывает:

Applicant -> Application data -> Application Processing -> Application record -> Applications Store
Manager -> Review decision -> Application Processing
Application Processing -> Application status -> Applicant

Главное различие:

BPMN - что происходит в процессе
DFD - какие данные движутся

В BPMN важны:

• события;
• задачи;
• gateway;
• участники;
• последовательность.

В DFD важны:

• источники данных;
• преобразования;
• хранилища;
• информационные потоки.

DFD и Sequence Diagram

Sequence Diagram показывает взаимодействие во времени.

Например:

React -> Django: POST /applications
Django -> PostgreSQL: INSERT
Django -> RabbitMQ: publish
Django -> React: 201 Created

DFD может описать тот же сценарий намного выше уровнем:

Applicant -> Application data -> Application Processing -> Application record -> Applications Store

Sequence Diagram отвечает на вопрос:

Кто кого вызывает и в каком порядке?

DFD:

Какие данные проходят между частями системы?

Поэтому:

Sequence Diagram - temporal interaction
DFD - information movement

DFD и ERD

ERD показывает структуру данных:

Student 1:N Application N:1 Program

DFD показывает движение данных:

Applicant -> Application data -> Application Processing -> Application Store

Связь между ними довольно естественная.

Если на DFD есть:

Application Store

в ERD, скорее всего, существуют сущности:

Application
Student
Program

Но соответствие не всегда один к одному.

Один Data Store на DFD может физически содержать десятки таблиц.

Например:

CRM Data Store

может включать:

users
applications
programs
documents
status_history
audit_log

DFD не обязана показывать внутреннюю реляционную структуру.

Как строить DFD с нуля

Для новой системы удобно идти сверху вниз.

1. Определить границу

Сначала сформулировать:

что именно считается системой

Например:

CRM образовательной программы

2. Найти внешние сущности

Например:

Applicant
Manager
Payment Provider
Education Platform
Email Provider

3. Найти входящие и исходящие данные

Например:

Application data
Review decision
Payment request
Payment result
Enrollment data
Notification

4. Построить Context Diagram

External Entities -> Data Flows -> CRM System

Без внутренней детализации.

5. Разделить систему на крупные процессы

Например:

Manage Applications
Manage Documents
Process Payments
Send Notifications
Generate Reports

6. Добавить Data Stores

Например:

Applications Store
Documents Store
Users Store
Payments Store

7. Соединить только реальные потоки данных

Каждая стрелка должна отвечать на вопрос:

Какие конкретно данные здесь проходят?

8. Декомпозировать сложные процессы

Manage Applications -> Receive -> Validate -> Review -> Update Status

9. Проверить balance

Входы и выходы дочернего уровня должны соответствовать родительскому.

10. Только после этого связывать DFD с реализацией

Например:

Data Flow -> REST / Event / Webhook
Data Store -> PostgreSQL / Redis / MinIO
Process -> Django service / Celery worker

То есть общий путь выглядит так:

Граница системы -> внешние сущности -> потоки данных -> процессы -> хранилища -> декомпозиция -> API и техническая реализация

Типичные ошибки

Первая ошибка - стрелки без названия.

Плохо:

Applicant -> CRM

Лучше:

Applicant -> Application data -> Submit Application

Вторая ошибка - процесс назван существительным.

Плохо:

Application

Лучше:

Process Application

Третья ошибка - Data Flow назван действием.

Плохо:

Send application

Лучше:

Application data

Четвёртая ошибка - прямое соединение External Entity и Data Store.

Плохо:

Applicant -> Applications Store

Лучше:

Applicant -> Application data -> Submit Application -> Application record -> Applications Store

Пятая ошибка - прямое соединение двух Data Stores.

Плохо:

Applications Store -> Archive Store

Нужен процесс преобразования или переноса.

Шестая ошибка - смешивание логической и физической модели.

Например:

Applicant -> React -> Validate Application -> PostgreSQL -> Notification Process -> RabbitMQ

Здесь смешаны:

• внешняя сущность;
• технология frontend;
• бизнес-процесс;
• конкретная СУБД;
• логический процесс;
• брокер сообщений.

Такая схема может быть полезна как отдельная физическая модель, но она должна строиться осознанно.

Седьмая ошибка - отсутствие Data Stores.

Если система принимает данные, использует их через несколько дней, но на диаграмме они нигде не сохраняются, модель неполна.

Восьмая ошибка - один гигантский уровень детализации.

Если на одной схеме одновременно находятся:

Submit Application
Validate Email
Check Program
Generate PDF
Publish RabbitMQ Message
Send Email
Create Student
Calculate Analytics

лучше разделить модель на Level 0 и Level 1.

Девятая ошибка - нарушение balance.

Если на дочернем уровне внезапно появляются новые внешние входы и выходы, родительская диаграмма больше не соответствует системе.

Десятая ошибка - попытка показать порядок выполнения через DFD.

DFD не предназначена для точного временного сценария.

Если важно показать:

сначала A -> потом B -> потом C

лучше использовать BPMN или Sequence Diagram.

Как проверить DFD

Перед завершением схемы полезно пройти по нескольким вопросам:

• Определена ли граница системы?
• Все ли External Entities действительно находятся снаружи?
• Каждый ли Process преобразует данные?
• Все ли Data Flows имеют понятные названия?
• Понятно ли, какие именно данные проходят по каждой стрелке?
• Есть ли Data Stores для данных, которые должны сохраняться?
• Нет ли прямых External Entity -> Data Store связей?
• Нет ли необъяснимых Data Store -> Data Store связей?
• Не смешаны ли logical и physical уровни?
• Сбалансированы ли Context Diagram, Level 0 и Level 1?
• Не пытается ли DFD показать временную последовательность вместо потоков данных?
• Можно ли по схеме определить основные API и интеграции?
• Понятно ли, где проходят чувствительные данные?

Если на эти вопросы есть ответы, DFD уже начинает выполнять практическую функцию, а не остаётся декоративной схемой.

Что важно запомнить

DFD описывает движение информации через четыре основных элемента:

External Entity - кто отправляет или получает данные
Process - что преобразует данные
Data Store - где данные хранятся
Data Flow - какие данные перемещаются

На верхнем уровне:

External Entities -> CRM System -> External Entities

На следующем:

Manage Applications
Manage Documents
Send Notifications
Generate Reports

После декомпозиции:

Manage Applications -> Receive -> Validate -> Store -> Review -> Update Status

При этом уровни должны оставаться сбалансированными.

DFD занимает своё место среди других моделей:

BPMN - ход бизнес-процесса
DFD - движение данных
ERD - структура данных
Sequence Diagram - взаимодействия во времени
OpenAPI - точный контракт передачи данных
C4 - архитектурная структура системы

Главный вопрос DFD можно сформулировать очень просто:

кто создаёт данные -> куда они идут -> какой процесс их изменяет -> где они сохраняются -> кто получает результат

Если схема позволяет быстро ответить на эти вопросы, значит модель построена правильно.