Показываю, как применять подход Чистая Архитектура Роберта Мартина в 1С

Забирай пример реализации Чистой Архитектуры для игры на Unity в боте: https://t.me/topgamemakers_bot?utm_source=picabu&utm_cam...
Кодовое слово для бот: ПримерНаЮнити

НАВИГАЦИЯ
00:00:00 — Вступление
00:00:55 — План стрима
00:02:08 — Как научиться писать правильно
00:09:33 — Чем помогает чистая архитектура
00:12:55 — Примеры проблем в архитектуре типовых
00:29:06 — Что такое DTO
00:35:16 — Что такое use case
00:43:13 — Дорабатываю типовой код
01:02:34 — Адаптер к типовому коду
01:17:31 — Презентер и вью
01:30:18 — Показываю чем хорош единый use case
01:43:20 — Сложный случай защиты от легаси кода через обработку
01:58:14 — Папки и почему без них плохо
02:01:14 — Vendor lock
02:04:22 — Ответы на вопросы
02:13:50 — Выводы

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 сюда же относятся Настройки/Константы/Параметры сеанса

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

🟡 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 — операционные принципы для устойчивых сервисов