Разберем задачу: спроектировать в ERP систему уведомлений по документам. — 29 июня 2026 г. в 11:36:08.166
Разберем задачу: спроектировать в ERP систему уведомлений по документам. Задачу предложил Иван Белокаменцев Пользователи должны получать уведомления, когда с документами происходят важные события: 👉 изменили контрагента 👉 добавили строку 👉 изменилась сумма 👉 документ отправили на согласование 👉 документ согласовали 👉 документ провели При классическом подходе 1С программисты в первую очередь проектируют метаданные. Это неверно. Начинать нужно со сценариев использования и бизнес-правил, а UI, хранилку и метаданные оставляем на потом. Бизнес-логику пишем так, чтобы без проблем менять UI, хранилку и метаданные в будущем. Сам процесс поиска сценариев использования и бизнес-правил мы в этом посте не обсуждаем. Концентрируемся только на том, как правильно изолировать слои: UI — Бизнес-логика — Хранилка Задачу разделим на три части: 1. Правила уведомлений 2. Документы как источник фактов 3. Уведомления как результат применения правил Слайд №2: Правила уведомлений С ними поработаем в классической технике, как все привыкли. Используем паттерн Active Record: Форма справочника → основной реквизит формы → стандартная запись → ПередЗаписью ПередЗаписью используем для демонстрации аналогии соблюдения инвариантов из DDD. DDD говорит: домен должен защищать свои инварианты. Поэтому добавим в ПередЗаписью некую простую валидацию, которая гарантирует, что состояние домена запишется в валидном виде. Если правила более сложные, например: проверить нет ли уже похожих правил уведомлений, то проверять эти инварианты в ПередЗаписью будет неверно, но этот вопрос мы сейчас обсуждать не будем. Слайд №3: Документы. Документ сам по себе не является входом в систему уведомлений. Входом является факт, который появился из документа. Сначала пройдем классический путь на базе технического жизненного цикла объекта: 👉 ПередЗаписью — найти факты изменения 👉 Объект.ДополнительныеСвойства — временно перенести факты 👉 ПриЗаписи — передать факты в сценарий Бизнес-логику уведомлений не складываем в обработчик ПриЗаписи Слайд №4: Отдельно рассмотрим сценарий, который не использует технические коллбеки платформы (ПередЗаписью, ПриЗаписи и тп) Если отказаться от работы в технике коллбеков, то получим максимально линейные и понятные сценарии использования. Иначе получаем набор строк, раскиданных по разным обработчикам. Если действие имеет конкретный бизнес-смысл, например «Отправка на согласование», то лучше сделать явный процесс: 👉 Форма передает намерение и идентификатор документа 👉 Рабочий процесс оркестрирует операции 👉 Хранилище согласуемых документов прячет физическую работу с документом 1С 👉 Операция применения правил уведомлений вызывается как отдельный шаг рабочего процесса Слайд №5: Сценарий применения правил уведомлений Он работает с фактами, правилами, получателями и уведомлениями. Он не должен знать, что именно в 1С является справочником, регистром или документом. На схемах со слайдов 3, 4, 5 обратите внимание на то, что бизнес-логика изолирована от метаданных и даже не знает где и как хранится состояние. Хранилки в данном случае — это общие модули, либо любой объект, если мы его передадим в бизнес-логику явным параметром. Главное, чтобы этот объект удовлетворял контракту, который требует бизнес-логика. А вот на схеме со слайда 2 UI, бизнес-логика, хранилка сплелись воедино Выводы: 👉 Метаданные 1С — это способ реализации 👉 Хранилище — это способ спрятать конкретный справочник или регистр от сценария 👉 Форма — это способ передать намерение пользователя в бизнес-логику и никакого отношения к месту хранение не имеет Схемы в хорошем качестве качайте тут PS жду ваши вопросы. Очень жду. Не стесняйтесь спрашивать и критиковать мою позицию 👉 Чат для общения и обсуждения 👈