YellowClub

Задачу предложил Иван Белокаменцев

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

🟡 изменили контрагента

🟡 добавили строку

🟡 изменилась сумма

🟡 документ отправили на согласование

🟡 документ согласовали

🟡 документ провели

При классическом подходе 1С программисты в первую очередь проектируют метаданные. Это неверно. Начинать нужно со сценариев использования и бизнес-правил, а UI, хранилку и метаданные оставляем на потом. Бизнес-логику пишем так, чтобы без проблем менять UI, хранилку и метаданные в будущем. Сам процесс поиска  сценариев использования и бизнес-правил мы в этом посте не обсуждаем. Концентрируемся только на том, как правильно изолировать слои: UI — Бизнес-логика — Хранилка

Задачу разделим на три части:

1. Правила уведомлений

2. Документы как источник фактов

3. Уведомления как результат применения правил

Слайд №2: Правила уведомлений

С ними поработаем в классической технике, как все привыкли. Используем паттерн Active Record (https://www.litres.ru/book/martin-fauler/shablony-korporativ...): Форма справочника → основной реквизит формы → стандартная запись → ПередЗаписью

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

Слайд №3: Документы.

Документ сам по себе не является входом в систему уведомлений. Входом является факт, который появился из документа.

Сначала пройдем классический путь на базе технического жизненного цикла объекта:

🟡 ПередЗаписью — найти факты изменения

🟡 Объект.ДополнительныеСвойства — временно перенести факты

🟡 ПриЗаписи — передать факты в сценарий

Бизнес-логику уведомлений не складываем в обработчик ПриЗаписи

Слайд №4: Отдельно рассмотрим сценарий, который не использует технические коллбеки платформы (ПередЗаписью, ПриЗаписи и тп)

Если отказаться от работы в технике коллбеков, то получим максимально линейные и понятные сценарии использования. Иначе получаем набор строк, раскиданных по разным обработчикам.

Если действие имеет конкретный бизнес-смысл, например «Отправка на согласование», то лучше сделать явный процесс:

🟡 Форма передает намерение и идентификатор документа

🟡 Рабочий процесс оркестрирует операции

🟡 Хранилище согласуемых документов прячет физическую работу с документом 1С

🟡 Операция применения правил уведомлений вызывается как отдельный шаг рабочего процесса

Слайд №5: Сценарий применения правил уведомлений

Он работает с фактами, правилами, получателями и уведомлениями.

Он не должен знать, что именно в 1С является справочником, регистром или документом.

На схемах со слайдов 3, 4, 5 обратите внимание на то, что бизнес-логика изолирована от метаданных и даже не знает где и как хранится состояние. Хранилки в данном случае — это общие модули, либо любой объект, если мы его передадим в бизнес-логику явным параметром. Главное, чтобы этот объект удовлетворял контракту, который требует бизнес-логика.  

А вот на схеме со слайда 2 UI, бизнес-логика, хранилка сплелись воедино

Выводы:

🟡 Метаданные 1С — это способ реализации

🟡 Хранилище — это способ спрятать конкретный справочник или регистр от сценария

🟡 Форма — это способ передать намерение пользователя в бизнес-логику и никакого отношения к месту хранение не имеет

Схемы в хорошем качестве качайте тут: https://disk.yandex.ru/d/_NMp76PvT5lRiw

PS жду ваши вопросы. Очень жду. Не стесняйтесь спрашивать и критиковать мою позицию

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

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

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

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

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

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

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

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

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