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