Чистая архитектура и 1С
Что здесь хорошо с точки зрения чистой архитектуры, а что стоит улучшить?
YellowClub
Желтый клуб — сообщество 1С программистов
Наша цель — расти профессионально вместе с единомышленниками из 1С сферы
Желтый клуб объединяет 1С разработчиков, 1С аналитиков и пользователей платформы 1С Предприятие.
Обсуждаем фишки по 1C программированию, управлению проектами, управлению командой, автоматизированное тестирование в 1С Предприятии.
Проводим регулярные стримы с интересными людьми из 1С сферы. Иногда встречаемся офлайн в разных городах.
18К
рейтинг
413 подписчиков
0 подписок
242 поста
14 в горячем
Пятничный мем
Показать полностью
1
Архитектурные ошибки 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 сюда же относятся Настройки/Константы/Параметры сеанса
Пишите в комментариях, какие ошибки вам мозолят глаза
Показать полностью
Какие архитектуры есть кроме «Чистой архитектуры» Роберта Мартина
Базовый ориентир
Самое важное в ПО — бизнес-правила (политики, use cases). Они — центр. UI/БД/фреймворки — детали. Хорошая архитектура позволяет отложить выбор деталей и менять их без боли
Правило зависимостей
Все зависимости идут внутрь, к бизнес-правилам. Внешние слои знают о внутренних, но не наоборот
Что в этом смысле можно называть архитектурой
🟡 Гексагональная (Ports & Adapters)
Четкие границы. Зависимости направлены к use cases. Внешнее входит через порты/адаптеры
🟡 Луковичная (Onion)
Домен в центре. Вокруг слои с инверсией зависимостей
🟡 Чистая архитектура (Clean Architecture)
Те же принципы в виде концентрических кругов: Entities (enterprise rules) → Use Cases (application rules) → Interface Adapters → Frameworks & Drivers
🟡 Плагинная/микрокернел
Тонкое ядро политик. Детали подключаются, как плагины через стабильные SPI. Полезно при высокой вариативности и внешних расширениях.
Фреймворк — это плагин к ядру, а не наоборот
🟡 DDD (стратегический уровень)
DDD отвечает, что мы строим и где проходят смысловые границы. Чистая архитектура диктует, как выстроить зависимости так, чтобы ядро не зависело от деталей. «Сущности Чистой архитектуры» — вся доменная сердцевина, а не только «DDD сущность»
🟡 BCE (Boundary–Control–Entity)
Раскладывает код вокруг use case. Boundary — интерфейсы к внешним акторам, Control — оркестрация сценария (use case), Entity — долгоживущие бизнес-объекты
🟡 DCI (Data–Context–Interaction)
Отделяет «данные» и «поведение сценария» через роли и контексты
Что условно считать архитектурой, если соблюдены доменные границы
🟡 Слоистая (n-tier) — приемлемо, когда центр тяжести в домене, а не в БД/фреймворке
🟡 Pipe-and-Filter (конвейеры) — когда фильтры реализуют политики, а I/O остается деталью
🟡 Event-Driven — если события — контракты на границах, а брокер — деталь
🟡 CQRS — уместно, когда разрез продиктован use cases, а не модой. Часто сочетается с Event Sourcing, но Event Sourcing— это уже про данные
Что скорее «детали/топология», а не архитектура домена
❌ Микросервисы / SOA / SCS / Serverless/FaaS — модели деплоя и интеграции. Внутри каждого сервиса архитектура все равно должна быть чистой/гексагональной
❌ Данные и хранение: Event Sourcing, Lake/Lakehouse, Lambda/Kappa, CDC/стриминг — механика хранения/доставки
❌ UI-паттерны: MVC/MVP/MVVM, Flux/Redux, микрофронтенды — презентационный слой = деталь
❌ Actor/Reactive — модель конкурентности/рантайма, не форма доменных границ
❌ Клиент-сервер, шина, брокер, P2P, space-based — сетевые/инфраструктурные топологии
Инструменты описания, управления и эксплуатации
🟩 C4, 4+1 — модели представления архитектуры
🟩 TOGAF/Zachman — корпоративные рамки управления
🟩 ATAM, ADR, fitness-functions — принятие и проверка решений
🟩 12-Factor/Cloud-Native — операционные принципы для устойчивых сервисов
Показать полностью
Пятничный мем
Показать полностью
1
Подготовил конфигурацию по мотивам вчерашнего поста: «Чистая архитектура в 1С»
Учел ваши комментарии. Спасибо за честный фидбек Илье, Сергею и Алексу 🙌
В конфигурации описал подробнее некоторые моменты, которые считаю важными.
Как забрать конфигурацию:
🟡 Открой бота 👉 ссылка на бота
🟡 Отправь кодовое слово ЧистаяАрхитектура
🟡 Бот сразу пришлет конфигурацию
Вопросы пишите тут в комментариях или прямо в боте. Соберу наиболее частые и сделаю ещё один апдейт.
😂 Репостните тому коллеге, который «всё решает в модуле формы» 😂
Показать полностью
Чистая архитектура в 1С (по Роберту Мартину)
Смысл: архитектура — это способ управлять изменениями.
Главный закон: зависимости направлены внутрь, к бизнес-правилам.
Слои (снаружи → внутрь)
Frameworks & Drivers → Interface Adapters → Use Cases → Entities
🧱 Entities (Сущности) — «о чём говорит бизнес вне компьютера»
Что это: устойчивые правила и инварианты, которые директор по продажам понимает без разговоров про таблицы и формы. Это плоская структура + чистые функции модуля, который создает/валидирует/изменяет структуру и тем самым заставляет инварианты выполняться. Живут дольше UI/БД.
Примеры инвариантов:
🟡 Количество ≥ 0 (целое для штучных товаров)
🟡 Сумма = Цена × Количество (округление по правилу X)
🟡 Нельзя отгрузить больше доступного остатка
Не путать с use case-правилами:
❌ «Не проводить заказ при долге > кредитного лимита»
❌ «Скидка > 15% требует утверждения»
В 1С размещение: Общие модули. Только чистые функции и простые типы/структуры
Запрещено: обращения к формам, ролям, Запрос, ДокументОбъект.
🎛 Use Cases (Бизнес-логика) — «как приложение выполняет операцию»
Роль: оркестрация шагов одной операции, использование Entities и портов. Пример: Оформить заказ, Начислить бонусы
Не делает: не открывает формы, не пишет в БД напрямую, не знает про роли/сеанс.
Вход/выход: DTO — плоские Структура / ТаблицаЗначений / Соответствие
(без ссылок на формы, ДокументОбъект, регистры, метаданные).
В 1С размещение: Общие модули
Важно: use case определяет контракты портов; реализация — в адаптерах.
🔌 Interface Adapters (Адаптеры)— мосты между миром и ядром
Здесь живут:
🟡 Controller: UI/HTTP → входной DTO use case
🟡 Presenter: ответ use case → данные для формы/HTTP
🟡 Реализации портов: Запрос, работа с ДокументОбъект/регистрами, HTTP, JSON
🟡 Маппинги: DTO ↔️ платформенные типы/объекты
Чего нет: бизнес-правил и сценарной оркестрации (они в Use Cases).
В 1С размещение: Общие/прикладные модули — там, где уместно.
🖼 Frameworks & Drivers — формы, платформа, внешние системы
Роль: доставить ввод/вывод, без бизнес-логики.
Что кладём:
🟡 Обработчики команд формы, HTTP-эндпоинты, регламентные задания
🟡 Обработчики событий: ПередЗаписью, ОбработкаПроведения и тп
🟡 Сбор и первичная UI-валидация (обязательность, формат, маски)
Чего не кладём: Запросы, ДокументОбъект.Записать(), работу с регистрами
— это в Interface Adapters.
На слайдах показал сквозной пример: «Оформить заказ»
Показать полностью
10
Микросервисы архитектура
❌ Трехзвенка ≠ архитектура
Архитектура — это способ управлять изменениями: отделить политику (бизнес-правила) от деталей (UI, БД, фреймворки) и направить зависимости внутрь, к правилам.
Почему это лишь «часть» архитектуры
🟡 Микросервисы. Это про деплой и интеграцию. Если внутри каждого сервиса перемешаны бизнес-правила, UI и SQL, то получаем распределенный монолит: «кашу по сети», а не архитектуру
🟡 Трехзвенка (UI → логика → БД). Шаблон слоев доставки, который легко деградирует: «логика» превращается в тонкий прокси к базе данных, а данные и события UI просачиваются в правила. В 1С это видно, когда:
🟩 запросы пишут прямо в модуле формы;
🟩 в процедуры бизнес-логики передают форму/элементы формы;
🟩 правила знают про структуру регистров и формат хранения.
Если бизнес-правила живут в формах и запросах — это не архитектура. Это детали, выдающие себя за архитектуру.