Спасибо за ваши комментарии.
Одна из больших проблем 1С-разработки — это модель мышления, которую во многом сама платформа нам прививает:
форма = объект метаданных = бизнес-объект = хранение в базе
Есть справочник. Есть форма элемента. Есть основной реквизит формы. Вывели реквизиты объекта на форму, пользователь поменял, нажал «Записать» — объект записался.
Для простого CRUD (создать, прочитать, обновить, удалить) — это нормально. Когда у нас справочник стран, единиц измерения или простых настроек — все хорошо. Там почти нет бизнес-логики: создал, изменил, записал, удалил.
Но большие 1С-системы — это не CRUD.
ERP, УТ, ЗУП, отраслевые конфигурации на миллионы строк кода — это системы со сложной бизнес-логикой. Тут изменение поля влияет на продажи, бухгалтерию, сервис, обмены, отчеты, права, документы, регламентные операции.
Из-за неверного подхода мы получаем справочники и документы с десятками реквизитов. Например, Контрагенты: реквизиты для продаж, бухгалтерии, сервиса, закупок, интеграций, отчетов. Все лежит в одном объекте. Как ответ на эту проблему в типовых разделили справочник на партнеров и контрагентов, но это все еще слишком крупное деление. И все еще смешивается модель хранения с бизнес правилами и UI.
А потом уже никто толком не понимает:
🟡 кто владеет этим реквизитом
🟡 в каком процессе он используется
🟡 кто имеет право его менять
🟡 какие правила на него завязаны
🟡 что сломается, если его изменить
🟡 можно ли использовать его в новой задаче
Проблема в том, что в одном объекте смешали разные бизнес-смыслы.
🟩 Продажи говорят «контрагент» и имеют в виду клиента
🟩 Бухгалтерия говорит «контрагент» и имеет в виду юридическое лицо для документов
🟩 Сервис говорит «контрагент» и имеет в виду клиента на обслуживании
Слово одно, а модели разные
И если мы продолжаем думать, что форма должна быть прямым отражением объекта хранения, мы неизбежно получаем огромные формы, скрытие реквизитов по ролям, сложные условия в коде и объекты, которые боятся менять.
В DDD это разделяется иначе.
🟩 Форма — это сценарий пользователя
🟩 Объект метаданных — это техническая структура
🟩 Хранение — это способ сохранить данные
🟩 Доменная модель — это бизнес-смысл и правила
Пользователь видит одну удобную карточку контрагента. Но внутри это не обязано быть одним объектом. Данные могут собираться из разных контекстов: продажи, сервис, бухгалтерия, закупки, интеграции.
Главное — перестать думать, что форма обязана один в один повторять то, как данные хранятся.
Для CRUD это нормально.
Для большой бизнес-системы — нет.