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

Но как только приложение усложняется и появляется бизнес-логика, то это только мешает. Как хранятся и где хранятся данные — это не важная для бизнес-логики деталь. С таким подходом мы можем на ленту менять хранилку и приложение этого не заметит. Сегодня данные храним в SQL, завтра в файле, послезавтра на удаленном сервере.

Может возникнуть вопрос: «Женя, у нас же 1С, у нас нет задачи хранить данные где-то еще кроме SQL».

Более простая аналогия с 1С: сегодня мы храним данные в справочнике, завтра в регистре сведений и нам не придется под это переписывать формы или бизнес-логику. Нужно будет только переписать адаптер (gateway) к хранилке.

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

Одна из больших проблем 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.

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

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

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