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

Перевод архитектуры на DDD подробно описан в статьях:

В них также представлена работа с сервисами, так что здесь мы опустим их подробное описание и сосредоточимся на реализации сервиса-обработчика. Настоятельно рекомендую прочесть статьи выше. В противном случае, будет намного труднее воспринимать логику создания сервисов.

Шаг 1. Сервис

Так как обработчики событий элементов смарт-процессов могут пригодиться на других проектах, создадим в Shared основной сервис для дочерних менеджеров смарт-процессов под названием “DynamicManager”. Таким образом мы сможем переключаться между ними в случае, если будут создаваться дополнительные. Для этого нам понадобятся:

Интерфейс для сервисов домена Shared, если его еще не существует:

Enum с типами менеджеров смарт-процессов:

Теперь мы можем приступить к созданию самого сервиса. Назовем его BaseDynamic, так как он использует стандартный функционал битрикса без сторонних библиотек. В сервисе будут 2 класса, для которых нужно создать собственные интерфейсы, а также дополнительный интерфейс для классов обработчиков по каждому смарт процессу – Repository:

Action – сборник методов переопределения операций над элементами смарт-процесса:

Controller – класс для транспортировки репозиториев смарт-процессов в классы операций:

Repository – отдельный класс с описанием событий для каждого типа смарт-процесса. Описываем столько событий, сколько мы хотим переопределить:

Также для полноты картины я создал пустой интерфейс для BaseDynamic:

И теперь, используя интерфейсы, мы можем создать для сервиса BaseDynamic:

Actions:

Controller:

И сам сервис:

Таким образом, при инициализации сервиса, у нас будет доступен его контроллер, однако, Actions надо будет получать отдельно для переданного репозитория. Об этом будет ниже.

Теперь, когда у нас есть подсервис, его необходимо определить в родительском:

Вот мы и создали пустой сервис, который можно получить методом DynamicManagerService::create(ServicesEnums::BASE->value). Пора наполнить его логикой.

Шаг 2. Контейнер

Как мы уже знаем, работа со смарт-процессами происходит посредством контейнеров \Bitrix\Crm\Service\Container, получаемых статическим методом getInstance(). Если углубимся в этот метод, то заметим, что он получает crm.service.container через сервис локатор. Этим же инструментом мы можем подменить контейнер на собственный. Давайте создадим один общий, как фабрику контейнеров через сервис DDD:

Теперь у нас есть класс для подмены контейнеров, но система его еще не видит. Для этого необходимо подменить его явно в файле "/local/php_interface/init.php" (а лучше, конечно, в собственном обработчике событий, чтобы не нагромождать файл и не грузить систему на каждом хите) код:

\Bitrix\Main\DI\ServiceLocator::getInstance()->addInstanceLazy('crm.service.container', [ 'className' => '\\App\\Shared\\Services\\DynamicManager\\BaseDynamic\\Fabric\\BaseDynamicContainerFabric', ]);

Таким образом, мы подменили инициализируемый сервис получения контейнера. Другими словами, теперь при каждом выполнении метода \Bitrix\Crm\Service\Container::getInstance(); мы получим инстанс созданного нами класса BaseDynamicContainerFabric.

Стоит подметить: мы использовали метод addInstanceLazy() для того, чтобы подмена происходила лишь когда выполняется метод getInstance() контейнера, а не при каждом хите страницы.

Так как операции над событиями относятся к сервису фабрик, нам нужно переопределить у контейнера метод их получения:

При этом, только у интересующих нас смарт-процессов. Метод getFactory() должен возвращать, как ни странно, фабрику (но иногда возвращает null) – то есть, дочерний объект абстрактной фабрики со своими определениями операций, а значит, мы можем переопределить и их. Для этого необходимо создать собственную фабрику.

Шаг 3. Фабрика

Так как мы создаем фабрику для смарт-процессов, создаваемый класс должен наследоваться от \Bitrix\Crm\Service\Factory\Dynamic – предка абстрактной фабрики:

Вместо того, чтобы плодить фабрики, я решил сделать одну для всех смарт-процессов, которые мы будем подключать по собственным репозиториям. То есть, фабрика всегда будет одного класса, но с разными параметрами. Для этого нам необходимо описать репозитории для тех смарт-процессов, события над элементами которых мы хотим изменить.

Шаг 4. Репозитории

Здесь нам необходимо на время отойти от слоя Shared и переключиться на Domains, так как нам предстоит описать события, применимые к конкретным смарт-процессам конкретного проекта. Создадим логическую структуру и класс событий \Domains\Dynamic\Events\VisitEvent.php для смарт-процесса "Посещения", унаследованный от созданного нами ранее интерфейса репозитория:

Стоит подметить: для определения событий мы будем добавлять действия к операциям событий, что всегда требует объект Item, над которым производится действие, и зафиксированный (обработанный нами) результат. Так что эти аргументы обязательны и всегда будут участвовать в наших переопределениях событий.

Определим одно событие для примера – onBeforeAdd:

Мы модифицировали результат выполнения события, но еще никуда его не подключили. Так как метод getFactory() контейнера получает идентификатор типа сущности (ENTITY_TYPE_ID) в качестве аргумента (его можно найти в таблице b_crm_dynamic_type или в ссылке открытого смарт-процесса), он и будет определять, нужно ли подключать репозиторий событий. Не придумал варианта лучше, чем создать список констант с соотношениями кодов смарт-процессов и их репозиториев, так как ID – нестабильная величина, а код всегда зависит от создающего смарт-процесс разработчика.

Сделаем такой список и определим в нем созданный репозиторий:

Также в Enum добавил метод tryFromName($name), позволяющий найти константу в списке по имени, если она существует.

Теперь, используя ID типа сущности, переданный в getFactory(), мы можем найти код смарт-процесса и проверить, существует ли у нас для него репозиторий. Создадим в контроллере 2 метода:

Получение кода смарт-процесса по его type ID:

Получение репозитория событий смарт-процесса по его коду:

Таким образом, мы можем проверять, описан ли у нас репозиторий для собираемого смарт-процесса и, в случае истины, подменять фабрику на собственную.

Шаг 5. Actions и Controller

Теперь нам необходимо описать каким образом методы из репозиториев будут попадать в операции. Для этого расширим классы Actions и Controller.

Добавим контроллеру свойство, имплементированное от RepositoryInterface, а также опишем для него унаследованные геттер и сеттер:

В Actions добавим конструктор, где мы будем запоминать переданный репозиторий:

А далее, тут же, в Actions, опишем новые действия для операций, полученные от интерфейса:

Поговорим о них немного подробнее. У родной фабрики битрикса есть методы определения операции, например: getAddOperation() (вернет \Bitrix\Crm\Service\Operation\Add). Но у нас есть возможность модифицировать операцию действиями – ее наследниками. Таким образом, вызывая у операции метод addAction(), мы добавляем ей новое действие, указав его тип (в нашем примере константа \Bitrix\Crm\Service\Operation::ACTION_BEFORE_SAVE) и экземпляр действия – анонимный класс-наследник Action, в котором переопределен метод process(). Здесь нам достаточно вызвать у сохраненного конструктором репозитория соответствующий метод с переданными Item-объектом, над которым совершается операция, и объектом результата выполнения, который может быть модифицирован. Именно поэтому в методах (которые так же, как и process(), возвращают объект Result) интерфейса репозитория важно соблюсти аргументы и возвращаемое значение.

Таким образом, можно добавить действия для следующих операций:

Добавление – \Bitrix\Crm\Service\Operation\Add;
Обновление – \Bitrix\Crm\Service\Operation\Update;
Удаление – \Bitrix\Crm\Service\Operation\Delete;
Копирование – \Bitrix\Crm\Service\Operation\Copy;
Конвертация – \Bitrix\Crm\Service\Operation\Conversion.

Шаг 6. Соединяем

Настало время подключить обработчики. Для начала опишем класс фабрики BaseDynamicFactoryFabric.

Добавляем свойство action, а также его геттер и сеттер:

Переопределяем методы родителя для определения операций. В нашем примере хватит getAddOperation():

То есть, мы получили стандартную операцию добавления и дважды изменили ее, вызвав методы класса Actions (мы определим свойство actions, которое возвращается методом $this->getActions(), позже).

Если необходимо переопределить больше операций, действуем по той же логике:

И, наконец, переходим к определению фабрики (метод getFactory() в классе BaseDynamicContainerFabric):

Пытаемся получить наш кастомный репозиторий для сущности, по которой собирается фабрика:

Сервисы в битриксе собираются часто, а исключение срабатывает, когда не получается найти для него кастомный репозиторий. Чтобы не спамить бессмысленными логами, просто возвращаем не интересующую нас фабрику как есть;
Получаем Actions по полученному репозиторию с помощью нашего сервиса:

Теперь у нас есть определения операций над сущностью с переданным типом. Проверяем, что мы можем взаимодействовать с сервисом (штатными методами контейнера):

Если мы все же можем добавить инстанс для сервиса, то определяем нашу фабрику, установив ей полученный по репозиторию класс Actions как соответствующее свойство, идентифицируем ее и отдаем подмененную:

Вот и всё! Теперь события будут подгружаться лишь для элементов тех смарт-процессов, репозитории которых были описаны.

Стоит подметить: перед переопределением событий необходимо подключить модуль crm.

Завершение

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

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

Ещё больше материала можно найти в канале DD Planet, где публикуются как мои, так и замечательные статьи моих коллег!

Сервис событий элементов смарт-процесса Bitrix24 на архитектуре DDD