Диаграмма потоков данных: источники, хранилища и границы доверия

Диаграмма потоков данных строится так: сначала определите внешние источники, процессы преобразования данных, хранилища и именованные потоки между ними. Сначала обозначьте границу системы, затем детализируйте внутренние перемещения, сохраняя состав входящих и исходящих данных. Добавьте примечания о разрешённых полях и границах доверия, чтобы проверяющие могли обнаружить непреднамеренное раскрытие информации.

Автор: Ai Flowi · Опубликовано 2026-10-10

Описывайте движение данных, а не последовательность принятия решений

Диаграмма потоков данных отвечает на вопрос: «Откуда берётся эта информация, где изменяется и куда поступает?» Она не показывает порядок выполнения согласований. Называйте процессы глаголами, хранилища — по содержащимся в них данным, а стрелки — по фактически передаваемому содержимому. Хранилище не может одобрить запрос: с прочитанными из него данными работает процесс.

Пример касается данных одобренного обращения, возвращаемых отправителю. Переданный отправителем текст изначально находится за пределами доверенной границы сервиса. Уполномоченный процесс проверки отдельно предоставляет запись с решением. Диаграмма не выводит факт одобрения из логического значения, переданного вызывающей стороной, и не утверждает, что конструктор рабочих процессов предоставляет очередь входящих для ручной проверки.

Сначала нарисуйте контекстную схему

Здесь «уровень 0» означает контекстную схему, где сервис представлен одним процессом; «уровень 1» раскрывает этот процесс. Команды используют разные правила нумерации, поэтому зафиксируйте свои. В этом коде Mermaid процессы обозначены скруглёнными фигурами, внешние сущности — прямоугольниками, а в развёрнутой схеме используется фигура хранилища. Группировка по границе доверия — дополнительная пометка, а не правило выполнения.

flowchart LR
    S[External sender] -- Enquiry fields --> P(Approved enquiry service)
    R[Authorized review process] -- Decision record --> P
    P -- Public enquiry receipt --> S

Контекстная схема намеренно показывает только два входящих контракта данных и один исходящий. Она не обещает одобрения каждого обращения. Подтверждение получения обращения может сообщать об ожидании, принятии или отклонении лишь тогда, когда это состояние установлено согласованным контрактом сервиса. При детализации сохраняйте исходный деловой смысл.

Детализируйте преобразования и хранилище проверок

Развёрнутая схема движения данных; граница сервиса обозначена пунктиром. Подписи стрелок описывают контракты полей, а не порядок выполнения.

flowchart LR
    S[External sender]
    R[Authorized review process]
    subgraph T[Service trust boundary]
        P1(1.1 Normalize permitted enquiry fields)
        P2(1.2 Associate reviewed version)
        D[(Review store)]
        P3(1.3 Project public receipt)
        P1 -- Normalized enquiry --> P2
        P2 -- Reviewed enquiry record --> D
        D -- Approved receipt fields --> P3
    end
    S -- Enquiry fields --> P1
    R -- Decision record --> P2
    P3 -- Public enquiry receipt --> S

Проверяйте согласованность схем по стрелкам, пересекающим границу, а не по количеству внутренних блоков. Поля обращения и запись с решением по-прежнему входят; публичное подтверждение получения обращения по-прежнему выходит. Если на уровне 1 внезапно появляется сообщение другому провайдеру, контекстная схема неполна. Если в хранилище проверок поступают персональные сведения, отсутствующие в контракте отправленных данных, детализация добавила необъяснённый источник.

Запись во внутреннее хранилище — концептуальное требование к процессу. Описанный ниже компонент Read Range не выполняет запись в хранилище. Различайте предполагаемую архитектуру и ограниченное упражнение с компонентами, особенно когда называете результат «одобренным».

Добавьте словарь данных

Этот словарь — предлагаемый проектный документ, а не действующая политика хранения. До запуска ответственные сотрудники должны утвердить назначение полей и сроки хранения. Пометка «Требуется решение» обозначает незавершённую работу; её нельзя считать разрешением хранить записи бессрочно.

Разрешённые контракты условного сервиса обращений с искусственными данными
Контракт данных	Разрешённые поля	Ответственная роль	Хранение и граница
Поля обращения	enquiry_ref, version, message	Команда приёма обращений	Отправитель → сервис; решите, нужно ли хранить исходное обращение
Запись с решением	enquiry_ref, reviewed_version, disposition, review_ref	Команда проверки	Уполномоченный процесс проверки → сервис; согласуйте хранение истории решений
Проверенная запись обращения	enquiry_ref, version, message, disposition, review_ref	Служба эксплуатации сервиса	Внутреннее хранилище; зафиксируйте ответственность за удаление и доступ
Публичное подтверждение получения обращения	enquiry_ref, disposition	Команда сопровождения API	Сервис → отправитель; без message, review_ref и метаданных подключения

Граница доверия отмечает смену того, кто контролирует данные или вправе их читать. Аутентификация не означает, что любое поле можно возвращать. Проверяйте стрелку от сервиса к отправителю отдельно от входящих данных уполномоченного процесса проверки: отправитель может получить решение, не видя внутренний идентификатор проверки.

Как найти передачу закрытых полей и необъяснённые хранилища на диаграмме потоков данных?

В условном черновике с искусственными данными разработчик подключает полную проверенную запись напрямую к публичному подтверждению получения обращения. Эта запись содержит review_ref, хотя словарь разрешает передавать через эту границу только enquiry_ref и disposition. Замените «полную запись» именованным набором разрешённых полей для формирования подтверждения и сравните его точный набор полей с публичным контрактом.

В другом черновике добавлено хранилище «Архив» с исходящей стрелкой, но без входящих данных. Проверяющим непонятно, кто его наполнил, какие поля в нём хранятся и относятся ли записи к одобренной версии. Либо удалите необъяснённое хранилище, либо добавьте фактический источник его данных, входящий контракт и ответственность за хранение. Не придумывайте поток в архив ради симметрии рисунка.

Проследите исправленный пример: отправитель передаёт идентификатор обращения «enquiry-demo», версию «v2» и искусственно созданное сообщение. Запись проверки должна указывать тот же идентификатор и версию. Сохранённое сопоставление может содержать внутренний идентификатор проверки; публичное подтверждение получения обращения содержит только идентификатор обращения и установленное решение. Это спроектированные наборы полей, а не записанные ответы сервиса.

Проверьте ограниченный пример чтения и формирования подтверждений в AI Flowi

Статус: задокументировано. Read Range и предлагаемое формирование подтверждения из разрешённых полей через JSON Operations описаны в каталоге; Ai Flowi не проверяла их совместную конфигурацию в рабочей среде.

Пример конфигурации, а не отчёт о проведённом тестировании

В справочнике Google Sheets и справочнике JSON Operations описаны интерфейсы чтения и преобразования, используемые в этом ограниченном упражнении.

Подготовьте учётную запись AI Flowi Workflow, закрытую таблицу с искусственными данными и собственную учётную запись Google, следуя инструкции по подключению Google; использование сервисов провайдера оплачивается отдельно.
Для Read Range задайте google_account и spreadsheet_id для тестовой таблицы, а range_name — равным ReviewDemo!A:B, где содержатся только идентификатор обращения и решение.
Изучите возвращённые строки, прежде чем предлагать сопоставление. Для JSON Operations передайте проверенный результат в data, выберите JQ Expression в operations и напишите query для наблюдаемой структуры-обёртки и контракта из двух столбцов.
Сверьте список сформированных подтверждений с исходящей стрелкой. Ни чтение, ни формирование подтверждения не реализуют концептуальную запись в хранилище на диаграмме.

Разберите несовпадение версий

Предположим, нормализованное обращение содержит идентификатор обращения enquiry-demo, версию v2 и исправленное искусственно созданное сообщение. Отдельная запись с решением указывает тот же идентификатор обращения, но reviewed_version=v1. Соединение только по идентификатору обращения прикрепило бы старое решение к новому содержимому. Процесс сопоставления должен оставить несовпадение неразрешённым; пока одобрение текущей версии не подтверждено, нельзя включать решение об одобрении в публичное подтверждение.

Добавьте в словарь правило сопоставления: проверенная запись требует совпадения и идентификатора обращения, и проверенной версии. Если два разных решения указывают одну и ту же пару, не выбирайте молча последнюю строку: выясните правило разрешения конфликтов у источника решений либо оставьте сопоставление неразрешённым. Это предлагаемые правила контракта данных, а не утверждение, что компонент чтения обеспечивает их соблюдение. Отдельные меры контроля полномочий описаны в требованиях к процессу согласования.

Теперь проследите три предлагаемые записи по словарю: v2 с решением для v1 остаётся неразрешённой; v2 с одним установленным решением для v2 может передать это решение; v2 с противоречащими решениями для v2 требует сверки. Во всех случаях наружу передаются поля enquiry_ref и disposition. Внутренний конфликт не оправдывает добавление истории решений, содержимого сообщения или идентификатора проверки в публичный ответ.

Считайте отсутствующие ячейки отсутствующей информацией. Пустое решение не означает отклонения, а отсутствие идентификатора обращения не позволяет выполнить сопоставление. Строка заголовков не является обращением. Узкий диапазон чтения полезен лишь после согласования этих контрактов в исходной таблице; он не может доказать происхождение данных или исправить избыточные права общего доступа. Сохраняйте неразрешённое сопоставление видимым в проекте, не придумывая запасное состояние.

Используйте готовые сценарии как подтверждающие данные, а не как доказательство архитектуры

Статус: протестировано. Очистка данных лидов сообщает: 32 из 32 проверок пройдены для конкретного сценария нормализации и добавления строк. Статус: протестировано. Таблица как JSON API сообщает: 25 из 26 проверок пройдены; непройденная проверка на утечку данных по-прежнему важна для исходящей границы.

Эти страницы содержат собственные точные сопоставления и результаты выполнения. Эта диаграмма показывает происхождение данных и разрешения на передачу полей; она не воспроизводит инструкции сборки этих сценариев и не переносит их результаты на архитектуру обращений. Определение интерфейса см. в глоссарии API, а пути решений и ответственности — в шаблоне карты процесса.

Завершите проверкой границ

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