Приветствую всех укротителей событий! Проникнувшись идеей разработки с использованием 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. Контейнер
Как мы уже знаем, работа со смарт-процессами происходит посредством контейнеров BitrixCrmServiceContainer
, получаемых статическим методом getInstance()
. Если углубимся в этот метод, то заметим, что он получает crm.service.container
через сервис локатор. Этим же инструментом мы можем подменить контейнер на собственный. Давайте создадим один общий, как фабрику контейнеров через сервис DDD:

Теперь у нас есть класс для подмены контейнеров, но система его еще не видит. Для этого необходимо подменить его явно в файле "/local/php_interface/init.php" (а лучше, конечно, в собственном обработчике событий, чтобы не нагромождать файл и не грузить систему на каждом хите) код:
BitrixMainDIServiceLocator::getInstance()->addInstanceLazy('crm.service.container', [
'className' => '\App\Shared\Services\DynamicManager\BaseDynamic\Fabric\BaseDynamicContainerFabric',
]);

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

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

Вместо того, чтобы плодить фабрики, я решил сделать одну для всех смарт-процессов, которые мы будем подключать по собственным репозиториям. То есть, фабрика всегда будет одного класса, но с разными параметрами. Для этого нам необходимо описать репозитории для тех смарт-процессов, события над элементами которых мы хотим изменить.
Шаг 4. Репозитории
Здесь нам необходимо на время отойти от слоя Shared и переключиться на Domains, так как нам предстоит описать события, применимые к конкретным смарт-процессам конкретного проекта. Создадим логическую структуру и класс событий DomainsDynamicEventsVisitEvent.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()
(вернет BitrixCrmServiceOperationAdd
). Но у нас есть возможность модифицировать операцию действиями – ее наследниками. Таким образом, вызывая у операции метод addAction()
, мы добавляем ей новое действие, указав его тип (в нашем примере константа BitrixCrmServiceOperation::ACTION_BEFORE_SAVE
) и экземпляр действия – анонимный класс-наследник Action, в котором переопределен метод process()
. Здесь нам достаточно вызвать у сохраненного конструктором репозитория соответствующий метод с переданными Item-объектом, над которым совершается операция, и объектом результата выполнения, который может быть модифицирован. Именно поэтому в методах (которые так же, как и process()
, возвращают объект Result
) интерфейса репозитория важно соблюсти аргументы и возвращаемое значение.
Таким образом, можно добавить действия для следующих операций:
-
Добавление – BitrixCrmServiceOperationAdd;
-
Обновление – BitrixCrmServiceOperationUpdate;
-
Удаление – BitrixCrmServiceOperationDelete;
-
Копирование – BitrixCrmServiceOperationCopy;
-
Конвертация – BitrixCrmServiceOperationConversion.
Шаг 6. Соединяем
Настало время подключить обработчики. Для начала опишем класс фабрики BaseDynamicFactoryFabric
.
-
Добавляем свойство
action
, а также его геттер и сеттер:

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

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

И, наконец, переходим к определению фабрики (метод getFactory()
в классе BaseDynamicContainerFabric
):
-
Пытаемся получить наш кастомный репозиторий для сущности, по которой собирается фабрика:

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

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

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

Вот и всё! Теперь события будут подгружаться лишь для элементов тех смарт-процессов, репозитории которых были описаны.
Стоит подметить: перед переопределением событий необходимо подключить модуль crm
.
Завершение
Помимо автора указанных в начале статей также хочется поблагодарить автора крайне полезной книги разработчика Bitrix24, без которой было бы очень тяжело разобраться в этой сложной и плохо документированной теме.
Дабы не растягивать данную статью кучей кода, оставляю ссылку на репозиторий, в котором находится весь код, собранный при написании статьи.
Ещё больше материала можно найти в канале DD Planet, где публикуются как мои, так и замечательные статьи моих коллег!
Автор: selfish-psycho