Архитектурные ошибки 1С разработчиков

Формат: как распознать → почему плохо → как починить

Лозунг: форма — тонкая, use case — толстый, инфраструктура — заменяемая

1) Толстые формы

Как распознать

🟡 В обработчиках формы есть Запрос = Новый Запрос(...), проверки

🟡 Утилиты в модуле формы: маппинг, форматирование дат/денег, локализация

🟡 Форма сама оркестрирует шаги: «резерв → бонусы → доставка»

🟡 HTTP-запросы из формы

🟡 «Болтливый» клиент–сервер: десятки мелких вызовов на сервер

🟡 Побочки: создание документов, смена статусов прямо из формы

Почему плохо

Форма (UI) начинает диктовать бизнес-правила. Логика расползается по обработчикам, тестируемость и переиспользование падают

Как починить

Форма → Контроллер → Use Case (UC) → Презентер → ViewModel → Форма

🟡 Форма не ходит ни в регистры, ни во внешние сервисы

🟡 Контроллер собирает вход, вызывает UC

🟡 UC решает, что делать

🟡 Презентер превращает результат в ViewModel для формы

🟡 Один серверный вызов на действие пользователя (без «болтовни»)

2) Запрософилия («Запрос = бизнес-логика»)

Как распознать

Инварианты и расчеты зашиты в тяжелых текстах Запросов:

🟡 Зашитые статусы (ГДЕ Состояние В ("Подтвержден","Оплачен"))

🟡 Сложные ветки ВЫБОР с бизнес-логикой

🟡 Параметры запроса похожи на политику: МаксДолг, ПорогБонуса, МинМаржа

Почему плохо

Плохо тестируется, изменения ломают все, правила теряются в языке запросов

Как починить

🟡 Правила — в UC. Запрос доставляет факты, UC принимает решения

🟡 Из запроса убираем политику: никаких «МожноОтгрузить», не вычисляем «КлассКлиента», не вычисляем бонусы

🟡 Запрос возвращает данные (остатки, суммы, статусы), а не вердикты

3) Запрос внутри Use Case

Как распознать

UC содержит текст Запроса, лезет в регистры

Почему плохо

🟡 Смешение политики и данных.

🟡 Заменить источник/оптимизировать запрос сложно, тесты тяжелеют

Как починить

UC вызывает порт репозитория. Текст запроса — в адаптере

4) «Сообщить()» на сервере

Как распознать

Серверная логика напрямую шлет пользователю Сообщить()

Почему плохо

Домен знает про UI, сценарии не тестируются, локализация — боль

Как починить

🟡 UC возвращает Result-модель: Успех/Ошибки/Предупреждения/Данные

🟡 Презентер решает, как показать: сообщения, подсветки полей

5) Событийная лапша

Как распознать

Логика распихана по ПередЗаписью, ОбработкаПроведения, подпискам. Порядок неочевиден

Почему плохо

Магия, неявные зависимости, сложно менять и тестировать

Как починить

🟡 События это только триггеры. События вызывают явный UC

🟡 Оркестрация/последовательность шагов пишем вне обработчиков событий

6) Use Case вызывает Use Case

Как распознать

«ОформитьЗаказ» изнутри вызывает «НачислитьБонусы» как другой UC

Почему плохо

UC превращается в оркестратор UC → нарушается SRP, тесты усложняются

Как починить

Композицию нескольких UC делает уровень выше: контроллер/фасад/оркестратор

Различайте порт и UC:

«Начислить бонусы» как порт — это простая запись значения

«Начислить бонусы» как UC — если есть правила/валидации/статусы

7) Общие модули-синглтоны вместо инъекции

Как распознать

UC напрямую вызывает общие модули

Почему плохо

Скрытые зависимости, сильная связанность, сложно тестировать/подменять

Как починить

🟡 Передавайте зависимости параметрами UC

🟡 Обращение к общим модулям допустимы в контроллерах/адаптерах, не в UC

PS сюда же относятся Настройки/Константы/Параметры сеанса

Пишите в комментариях, какие ошибки вам мозолят глаза

🌕 Подписывайся на @Желтый клуб — 1С программирование