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

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

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

Оставайтесь на связи и давайте потихоньку изучать тему Архитектуры, как она понимается в программировании в целом, а не в мире 1С

PS спасибо за каменты. они помогают мне лучше понимать, на что делать упор.

Спасибо за ваши комментарии.

Одна из больших проблем 1С-разработки — это модель мышления, которую во многом сама платформа нам прививает:

форма = объект метаданных = бизнес-объект = хранение в базе

Есть справочник. Есть форма элемента. Есть основной реквизит формы. Вывели реквизиты объекта на форму, пользователь поменял, нажал «Записать» — объект записался.

Для простого CRUD (создать, прочитать, обновить, удалить) — это нормально. Когда у нас справочник стран, единиц измерения или простых настроек — все хорошо. Там почти нет бизнес-логики: создал, изменил, записал, удалил.

Но большие 1С-системы — это не CRUD.

ERP, УТ, ЗУП, отраслевые конфигурации на миллионы строк кода — это системы со сложной бизнес-логикой. Тут изменение поля влияет на продажи, бухгалтерию, сервис, обмены, отчеты, права, документы, регламентные операции.

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

А потом уже никто толком не понимает:

👉 кто владеет этим реквизитом

👉 в каком процессе он используется

👉 кто имеет право его менять

👉 какие правила на него завязаны

👉 что сломается, если его изменить

👉 можно ли использовать его в новой задаче

Проблема в том, что в одном объекте смешали разные бизнес-смыслы.

➖ Продажи говорят «контрагент» и имеют в виду клиента

➖ Бухгалтерия говорит «контрагент» и имеет в виду юридическое лицо для документов

➖ Сервис говорит «контрагент» и имеет в виду клиента на обслуживании

Слово одно, а модели разные

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

В DDD это разделяется иначе.

👉 Форма — это сценарий пользователя

👉 Объект метаданных — это техническая структура

👉 Хранение — это способ сохранить данные

👉 Доменная модель — это бизнес-смысл и правила

Пользователь видит одну удобную карточку контрагента. Но внутри это не обязано быть одним объектом. Данные могут собираться из разных контекстов: продажи, сервис, бухгалтерия, закупки, интеграции.

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

Для CRUD это нормально.

Для большой бизнес-системы — нет.

Стратегический DDD отвечает не на вопрос «как написать код», а на более важный вопрос: как правильно разложить предметную область.

Стратегический DDD помогает:

1. Выделить ключевые бизнес-домены и понять, где находится основная ценность продукта

2. Найти границы контекстов: где одна модель заканчивается, а другая начинается

3. Определить язык, на котором бизнес и разработка говорят об одних и тех же вещах

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

Стратегический DDD помогает найти границы будущих модулей: не технических, а бизнес-смысловых.

Пример из мира 1С: «Работа с файлами», «Печать», «Пользователи», «ОбщегоНазначения» — это техническая нарезка.

Она отвечает на вопрос: «какой механизм мы используем?»

А стратегический DDD предлагает другой вопрос: «в каком бизнес-контексте это живет?»

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

Механизм может быть общим.

Но бизнес-смысл и правила должны жить внутри своих контекстов.

Тактический DDD — это уже про конкретные строительные блоки: Entity, Value Object, Aggregate, Repository, Domain Service и так далее. Про тактический уровень поговорим позже.

А пока предлагаю простое упражнение.

Возьмите техническое задание, описание продукта или большой кусок кода и отправьте его в ChatGPT с промптом:

Выступи как архитектор программного обеспечения. Проанализируй это через призму стратегического DDD. Выдели возможные домены, bounded contexts, ключевые бизнес-понятия и зоны, где модель может быть размыта или неправильно разделена. Дай архитектурный вердикт и рекомендации.

Делитесь в комментариях: узнали ли вы что-то новое после анализа.

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

Азы на стриме освещать не буду. Что-то верхнеуровневое дам, но ожидаю, что аудитория к этому моменту немного подготовится.

Рекомендую оставаться на связи и активно участвовать в обсуждениях в комментариях.

Первое, с чего начну, — это книги по DDD.

🟡 Есть книга Эрика Эванса Domain-Driven Design. Это прародитель DDD. Тут без вариантов.

Но книга написана сложным языком. Засыпаешь после 2 страниц чтения.

И примеры местами не самые удачные, потому что сейчас так не пишут и так уже не думают. DDD развивается.

🟡 А вот что я рекомендую почитать — это Влад Хононов, Learning Domain-Driven Design.

Она проще читается. Более прикладная. Примеры лучше.

И еще мне нравится, что Влад добавил отдельный раздел по анализу архитектурных паттернов: слоистая архитектура, порты и адаптеры. Чем они отличаются, зачем нужны и как это связано с DDD.

То есть вы за одну книгу чуть-чуть въедете и в DDD, и вообще в архитектурные подходы.

Потом можно отдельно читать «Чистую архитектуру» Мартина. Но у Мартина нет акцента на моделирование домена. А домен — это суть приложения.

Поэтому на сегодня рекомендация такая:

Эванса можно читать, но на свой страх и риск. Это классика, но тяжелая.

Хононова — рекомендую как первую книгу по DDD.

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

Поэтому начинаем с этого пункта.

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