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...

Спасибо за вопросы в боте!
Забрал их в работу при подготовке 🤝

Больше 700 человек проголосовали за стрим по теме DDD.
Вот это вы поднажали 🔥

Я не ожидал такого количества. Думал, посмотрим на реакцию и уже решим, насколько тема вам нужна. Теперь всё ясно без дополнительных исследований.

Ответственности стало ещё больше. Постараюсь сделать стрим содержательным и полезным.

Разберём всё на конкретном примере в 1С: посмотрим конфигурацию, код и то, как можно отделять бизнес-логику от объектов системы.

Вдвойне приятно, что голосованием вы не ограничились.

На просьбу прислать свои вопросы и темы вы написали около 60 ответов. Причём не просто «расскажите про архитектуру», а описали вполне конкретные проблемы:

👉 как внедрять нормальную архитектуру в существующую систему;
👉 что делать с типовыми конфигурациями;
👉 как делить систему на слои;
👉 как отделять логику от интерфейса;
👉 как объяснять архитектурные решения коллегам и не превращать очередную доработку в новый технический долг.

Часть вопросов затронем во время стрима. Остальных хватит ещё на несколько отдельных разборов.

Спасибо, что так включились. Это помогает понять, какие темы действительно важны разработчикам.

Открытый стрим состоится 23 июля в 19:00 МСК

Информация о трансляции здесь: https://t.me/+lOd3N5NzaF4zM2Yy

Стриму по DDD быть.

Вижу, что интерес есть, поэтому ставим дату:

Четверг 23 июля в 19:00 МСК

Тема: «DDD и слои в 1С-разработке с примером конфигурации, кодом и разбором, как это применять в 1С мире»

Пока по количеству регистраций мы вмещаемся в закрытый Zoom. Если так и останется, то сделаем камерный формат без записи: спокойно все обсудим и пообсуждаем голосом.

Если доберем 200+ регистраций, тогда проведем большой стрим с записью.

На стриме разберем:

👉 почему думать от UI или метаданных — путь к комку грязи в архитектуре;

👉 что такое «проектирование архитектуры» на самом деле;

👉 как выделять слои и зачем они нужны;

👉 как проектировать домен по DDD;

👉 зачем вообще нужен DDD, если у нас есть справочники, документы, регистры и типовые механизмы;

Пока с активностью в канале приторможу.

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

Если хотите попасть на стрим — регистрируйтесь в боте.

По количеству регистраций финально выберем формат: закрытый Zoom без записи или большой стрим с записью.

Регистрируйтесь тут: https://r.bothelp.io/tg?domain=topgamemakers_bot&start=c...

Вчера жена сказала мне неприятную вещь.

Мы обсуждали планы на ближайшие две недели, и оказалось, что много времени уйдёт на подготовку к стриму по DDD в 1С. Я хочу не просто выйти и поговорить про DDD и хорошую архитектуру, а доработать типовую конфигурацию и показать, как DDD и слои могут выглядеть в 1С. Показать, какие задачи можно с помощью такого подхода решать.

Я поделился, что после тестов по архитектуре у меня странное ощущение 🤔

Вроде бы большинство отвечает правильно.

Видит ошибки.

Понимает, где проблема.

А потом пишут:

“У нас так никто не делает”.

“Это должна вся команда так писать”.

“В реальных проектах на это нет времени”.

“Мы всё понимаем, но работаем как работаем”.

И вот жена смотрит на меня и говорит:

«Жень, тебе не кажется, что эта архитектура никому не нужна, кроме тебя? Ты сейчас две недели будешь носиться с этой конфигурацией, готовить стрим, разбирать DDD и чистую архитектуру.

А может, это мало кому нужно? Может, лучше уехать в отпуск, лечь у бассейна и нормально отдохнуть?

Потому что людям, кажется, интересно пообсуждать архитектуру, поставить правильный ответ в тесте, написать умный комментарий.

Но применять это в работе — нет.

И тогда зачем тебе делать стрим, если в итоге это нужно трём людям?»

И я расстроился...

Первое желание — спорить и сказать, что архитектура нужна.

Что без неё 1С-проекты превращаются в ком грязи, который страшно трогать.

Что “нет времени на архитектуру” потом превращается в “нет времени на добавление новых фич”.

Гнев прошел и пришлось согласиться,  что вопрос нормальный.

Проблема в пропасти между:  “я понимаю” и “я так пишу”.

И мне интересно, насколько эта пропасть вообще кому-то мешает. Может, я правда смотрю на это через свою профессиональную деформацию. А может, рынку достаточно знать, как правильно, но продолжать писать как принято.

Отсюда вопрос👇

Вам нужен большой стрим, где я покажу, как DDD и чистая архитектура могут выглядеть в 1С мире?

Или это тема для закрытого разбора в ZOOM на несколько человек, которым реально надо так писать, а не просто послушать?

Сделал голосовалку в боте, который сохранит ваш ответ и пригласит на тот формат, за который вы проголосуете.

Жду ваши честные ответы

Голосовать тут: https://r.bothelp.io/tg?domain=topgamemakers_bot&start=c...

Стас требует доказательства, что хорошая архитектура помогает решить проблему превращения кода приложения в большой ком грязи.

Проблема выглядит так:

кодовую базу все еще можно запускать, но развивать ее становится все тяжелее. Разработчики все больше времени тратят на исправление ошибок, согласование изменений и понимание старого кода, а не на развитие функциональности.

Сразу замечу: Мартин и его «Чистая архитектура» — не единственный пример хорошего архитектурного подхода. Есть еще гексагональная архитектура, луковая архитектура. Все эти подходы говорят об одном: защищайте бизнес-логику от UI, хранилищ, фреймворков и прочей инфраструктуры.

Нашел исследования по этой теме. Они сводят эту проблему к конкретным цифрам:

— времени

— ошибкам

— стоимости сопровождения

👉 В исследовании Code Red: The Business Impact of Code Quality https://ar5iv.labs.arxiv.org/html/2203.04374 изучили 39 реальных промышленных кодовых баз и активность в 30 737 файлах. Авторы связывали качество кода с задачами из системы учета, историей изменений и временем разработки.

Выводы такие:

— код низкого качества содержит примерно в 15 раз больше дефектов;

— задачи в таком коде решаются на 124% дольше;

— худшие случаи по времени решения становятся примерно в 9 раз длиннее.

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

👉 Другая статья — Technical Debt and System Architecture https://www.hbs.edu/ris/Publication Files/2016-JSS Technical Debt_d793c712-5160-4aa9-8761-781b444cc75f.pdf . В ней исследовали две большие системы: примерно по 20 000 компонентов в каждой. Авторы смотрели на связность компонентов:

— кто от кого зависит

— где появляется центральный клубок

— насколько изменение в одном месте может потянуть изменения в других

Там хорошо видно, что дефекты распределяются по системе неравномерно.

В первой системе центральные компоненты составляли около 31% файлов, но давали почти 70% всей работы по дефектам. При этом периферийные и изолированные файлы составляли около 30% системы, но давали всего 1.1% работы по дефектам.

Во второй системе ядро составляло около 26% файлов, но давало около 62% всей работы по дефектам. В этой же системе дефекты в 5.8% периферийных файлов.

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

В этой же работе есть финансовая оценка.

В одной из систем строка кода в центральных компонентах стоила в сопровождении в 15 раз дороже, чем строка кода на периферии.

👉 Еще одно крупное исследование — работа Google Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment https://par.nsf.gov/servlets/purl/10590239

Там изучили 1252 проекта на C++ и Java и данные по 7200 разработчикам. Авторы смотрели на архитектурную сложность через несколько признаков:

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

— насколько части системы развязаны между собой

— сколько есть циклов между файлами и других структурных проблем

Вывод из исследования:

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

===

Итого

Плохая архитектура приводит к тому, что:

— становится больше ошибок;

— задачи делаются дольше;

— больше времени уходит на исправления вместо новых возможностей;

— центральные компоненты становятся дорогими в сопровождении;

— изменение одного места заставляет проверять слишком много связей.

Хорошая архитектура решает обратную задачу: уменьшает связность, ограничивает распространение изменений и не дает бизнес-логике утонуть в UI, базе данных и инфраструктуре.

Вопрос в том, есть ли в системе границы, которые помогают ей развиваться

👉 Подписывайся на @YellowClub,