YellowClub

Давно задолжал базу знаний по чистой архитектуре.

Конфигурацию для JWT-аутентификации и авторизации через 1С отдал, а полную подборку материалов так и не собрал. Исправляюсь.

Подготовил в одном месте материалы, которые помогут двигаться в теме архитектуры более-менее последовательно.

Что внутри:

👉 Маршрут изучения архитектуры для 1С-разработчика

В «маршруте» я разложил все по шагам:

— зачем вообще нужна архитектура;

— почему use case важнее формы;

— что такое доменная модель;

— зачем нужны диаграммы взаимодействия;

— как думать про ответственности и зависимости;

— почему функции с побочными эффектами ухудшают код;

— где появляются границы и слои;

— зачем нужны тесты;

— как работать с легаси.

👉 Видео по архитектуре

Четыре стрима, которые лучше смотреть по порядку:

— Почему код типовых так сложно понимать

— Интерфейсы и классы в 1С

— Архитектура БСП

— Архитектурный разбор обработок Контура и Диадок для ЭДО

Если времени мало, я бы смотрел первый и третий.

Первый дает общее понимание, третий поясняет на примере БСП

👉 Кейс «от я не знаю, что такое авторизация» до конфигурации с JWT за 8 дней

Это, пожалуй, самый ценный материал в подборке.

Я почти не понимал предметную область авторизации в HTTP API: JWT, токены, подписи, сроки жизни, scopes, периметр, безопасность.

А в итоге за 8 дней с помощью ChatGPT собрал рабочую конфигурацию.

Часто слышу «дайте пример реальных задач под 1С, какие делают нейронки». Показываю полный процесс работы. И это сильно проще, чем кажется:

— как задаю вопросы;

— как наращиваю контекст;

— как фиксирую результат в ТЗ;

— как прошу смотреть на решение глазами архитектора;

— как из каши неизвестных терминов постепенно собирается нормальная архитектурная форма.

Там же оставил ТЗ по подсистеме аутентификации и авторизации HTTP API.

👉 Инструкция, как подключить и оплатить ChatGPT из России

Если вы еще не пользуетесь GPT, Claude или аналогами — это проблема.

Не нужно начинать с агентов, MCP и сложных пайплайнов.

Для начала достаточно работать в чате.

Главное — научиться разговаривать с ИИ, как с напарником, а не ждать магии от одного промпта.

Забирайте базу знаний в боте: https://r.bothelp.io/tg?domain=topgamemakers_bot&start=c...

Он зашел ко мне на VIP-тариф с «Автором курса». Интересная получилась беседа на тему нотации C4.

Он делится болью:

— Слушай, мы так бодренько на своих архитектурных комитетах разруливаем уровень C1, C2, а дальше мы не знаем, что делать? Как код то писать?

И действительно. А дальше-то что?

C1 в C4 — это уровень контекста системы: какую систему мы вообще делаем, кто ей пользуется, какие системы находятся вокруг нее и где проходят ее внешние границы.

C2 — это уже контейнеры: на какие крупные исполняемые части делится наша система. Например: web-приложение, mobile app, backend, база данных и так далее.

Если внимательно посмотреть на эти первые уровни C4, то по факту они говорят нам:

Ребят, займитесь-ка инфраструктурой. Опишите-ка физическое разделение вашего приложения: здесь web, здесь mobile, здесь backend, здесь база данных, здесь еще что-нибудь.

Если мы рисуем таким образом совершенно разные приложения — приложение для больницы, интернет-магазин, управление производством, — то плюс-минус получим одинаковые диаграммы.

Где-нибудь будет авторизация, backend, mobile, база данных, еще пара внешних систем.

Все.

Квадратики плюс-минус одинаковые.

Но ведь суть этих приложений вообще не в этом. Суть приложения для больницы не в том, что у него есть backend и база данных.

Все самое интересное сидит внутри одного квадратика с надписью Backend.

А как этот Backend написать?

👉 Как внутри него разделить ответственность?

👉 Где проходят логические границы?

👉 Какие там бизнес-правила?

👉 Какие инварианты?

👉 Что к чему относится?

👉 Кто за что отвечает?

Это и есть настоящие проблемы. И рисованием квадратиков эти проблемы не решить.

Причем сами авторы C4 говорят: C4 не задает вам процесс проектирования архитектуры. Это модель для визуализации и коммуникации. Она позволяет посмотреть на систему с разным увеличением, но не говорит вам, как эту систему правильно спроектировать.

Если воспринимать C4 как процесс проектирования и начинать с C1 → C2, то смещается фокус внимания. Мы начинаем слишком рано думать о том, чем надо заниматься в самом конце.

Конечно, бывают системы, где основная сложность именно техническая. Какой-нибудь проект с телеметрией, поисковый движок. Там вопросы latency, распределения нагрузки и прочего могут стать самым важным.

Если мы говорим про бизнесовые приложения на 1С, то огромный кусок инфраструктурных проблем у нас уже решила фирма 1С. У нас есть платформа. И в ней уже очень много всего есть.

Поэтому если мы начинаем архитектуру 1С-приложения с рассуждений уровня C1/C2 и слишком сильно на этом концентрируемся, то уведем фокус внимания от самого важного: От бизнес-логики.

В итоге получим обычный распределенный ком грязи.

Поэтому, ребятушки, C4, ArchiMate и остальные подобные штуки — прекрасные инструменты, чтобы что-нибудь пообсуждать.

Для коммуникации — замечательно.

Чтобы верхнеуровнево показать систему — хорошо.

Чтобы посмотреть на нее с разных сторон — тоже хорошо.

Но они не дают вам процесса проектирования архитектуры.

Они не для этого.

Сначала нужно понять предметную область и бизнес-правила.

Найти логические границы.

Разделить ответственность.

Спроектировать приложение именно логически.

А уже потом, когда все это появилось, открывайте C4 и рисуйте красивые квадратики: где это будет физически жить, какие приложения между собой общаются, какие контейнеры есть и так далее.

Основная проблема — это логические границы.

Над ними надо работать.

А как потом хорошо разделенные логические части разложить по физическим границам, приложениям и серверам — это более простой вопрос.

А вот если вы логически ничего не разделили и сразу занялись физическим делением — ничего хорошего из этого не получится.

На стриме в четверг поговорим об этом. Второй день переписываю бизнес правила, чтобы они лучше читались, выделяю инварианты и провожу четкие границы. И когда с этим закончу — у меня не будет проблем, чтобы выбрать модель хранение или модель презентации.

Работа с доменом — это очень сложно. Это не тоже самое, что квадраты рисовать или кнопки.