Архитектурные ошибки 1С разработчиков — 23 марта 2026 г. в 15:50:17.044
Архитектурные ошибки 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 сюда же относятся Настройки/Константы/Параметры сеанса А какие ошибки вам мозолят глаза? 👉 Пишите в чате