Идемпотентность в 1С: реальные анти-паттерны из типовых конфигураций

Типовые конфигурации 1С не проектировались как строго идемпотентные системы.
Они проектировались как:

  • «достаточно надёжные при корректной эксплуатации»,
  • с сильным допущением на ручное управление и регламентированную дисциплину пользователей.

Проблема начинается там, где типовые решения:

  • попадают в интеграции,
  • работают в асинхронном режиме,
  • становятся ядром бизнес-процессов.

Анти-паттерн №1

«Создаём документ, если не нашли»

Как выглядит в типовых

Если Не ЗначениеЗаполнено(Документ) Тогда
    Документ = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
    ...
    Документ.Записать();
КонецЕсли;

Почему это анти-паттерн

  • Поиск ведётся по косвенному признаку:
    • дате,
    • номеру,
    • реквизиту,
    • контрагенту.
  • Повторный вызов:
    • создаёт новый документ,
    • вместо восстановления состояния.

❌ Повтор операции ≠ тот же результат
❌ Документ = побочный эффект, а не состояние

Архитектурная ошибка

Документ используется как:

маркер факта выполнения операции

Но:

  • документ — не маркер,
  • документ — следствие бизнес-состояния.

Как должно быть

  • Явный бизнес-ключ операции:
    • внешний ID,
    • номер заказа,
    • ID транзакции.
  • Документ либо:
    • один,
    • либо обновляется,
    • либо операция отклоняется как повторная.

Анти-паттерн №2

«Регламентное задание считает приращение»

Типовая логика

  • взять данные за период,
  • рассчитать разницу,
  • дописать движения в регистр.

Что происходит на практике

  1. Задание упало на середине
  2. Администратор перезапустил
  3. Часть данных:
    • задвоена,
    • часть отсутствует,
    • контрольных сумм нет

Ключевая ошибка

Регистр используется как:

журнал изменений

Вместо:

проекции состояния

Почему это не идемпотентно

  • повтор ≠ тот же результат
  • результат зависит от истории выполнения, а не от входных данных

Архитектурно правильно

  • либо:
    • полный пересчёт регистра,
  • либо:
    • расчёт состояния + синхронизация по ключу,
  • либо:
    • очистка и воспроизведение.

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

Анти-паттерн №3

«Флаг обработки» как иллюзия идемпотентности

Типовая защита

Если Не Обработано Тогда
    ВыполнитьДействие();
    Обработано = Истина;
КонецЕсли;

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

  • флаг:
    • может не сохраниться,
    • может сохраниться частично,
    • может устареть при изменении входных данных.

❌ состояние = флаг
❌ входные данные не контролируются

Архитектурная проблема

Флаг не является инвариантом.

Он не отвечает на вопрос:

соответствует ли текущее состояние целевому?

Правильный подход

  • Сравнение:
    • текущего состояния
    • с целевым состоянием
  • Флаг — максимум оптимизация, но не логика.

Анти-паттерн №4

«Повторный обмен — повторная обработка»

Типовая интеграция

  • файл / сообщение пришло
  • обработано
  • подтверждение не дошло
  • сообщение пришло снова

❌ типовая обработка:

  • обрабатывает всё заново
  • создаёт дубли
  • или портит данные

Причина

  • нет:
    • ключа сообщения,
    • журнала обработки,
    • инварианта результата.

Архитектурно правильно

  • входящее сообщение = идентифицируемая операция
  • повтор:
    • либо noop,
    • либо восстановление состояния,
    • либо явный отказ.

Анти-паттерн №5

Документ как транзакция

Очень распространено в ERP:

«Документ = бизнес-операция»

И:

  • если документ провёлся — значит операция состоялась,
  • если нет — повторяем.

Почему это опасно

  • документ:
    • может частично записаться,
    • может провести часть регистров,
    • может откатиться не полностью.

Повторное проведение ≠ безопасный повтор операции.

Архитектурный вывод

Документ не должен быть границей идемпотентности.
Граница — это:

  • бизнес-операция,
  • бизнес-ключ,
  • инвариант результата.

Главная системная проблема типовых конфигураций

Типовые решения:

  • не проектируются под повторяемость,
  • предполагают:
    • линейный сценарий,
    • «аккуратного пользователя»,
    • «один раз и навсегда».

Архитектор, который переносит эти допущения в:

  • интеграции,
  • высокую нагрузку,
  • распределённые системы —

закладывает будущий ручной ад.

Альтернативный взгляд (когда анти-паттерн допустим)

Иногда типовые анти-паттерны допустимы:

  • в закрытых ручных процессах,
  • при жёстком регламенте,
  • при контролируемом количестве операций.

Но:

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

Что если я заблуждаюсь?

Возможно, типовые решения достаточны
Но только до первой серьёзной интеграции. 👉 Проверка:
есть ли внешние источники, которые могут прислать повтор?

Возможно, я переоцениваю требования к устойчивости
Иногда бизнесу реально дешевле чинить руками. 👉 Проверка:
сколько стоит один инцидент + разбор?

Возможно, ты работаешь в низкорисковой зоне
Низкая нагрузка, редкие повторы. 👉 Проверка:
что будет при масштабировании ×5?

+ There are no comments

Add yours