Какая должна быть архитектура приложения, без ActiveRecord в Yii2?

Вот мы на скорую руку создали проект на AR (ActeveRecord) запросы через него, запись и обновление. Для старта нового проекта я считаю это вполне норм, при том, что проект может не взлететь.

Но вот проект живет, модели AR распухают логикой. Растет база, вместе с ней объемы обрабатываемой информации. И нужно уже задумываться, как логику вынести из AR (behaviors, AfterSave, BeforeSave) в первую очередь, чтоб её можно было применять при batchInsert и batchUpdate.

Небольшое отступление, по поводу логики, примеры:
  • Изменился статус заказа, нужно отправить уведомления на почту, телеграм и тп. Записать в историю изменения суммы заказа, статуса.
  • Обновить/удалить кэш или обновить индекс в elasticSearch
  • Отправить на модерацию данные
  • И все тому подобное


---
Есть мысли, что нужно это все вынести в обработчики и события, например какой то класс занимается обработкой измененных данных (сравнивает старые данные с новыми) и создает события, причем выполнения действий по событиям должны обрабатываться где то в очереди, в отдельно, чтоб текущую задачу по batchInsert и batchUpdate в несколько тысяч записей это не тормозило.

Но как это должно выглядеть архитектурно, какие нюансы и подводные камни?

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

Хотелось бы увидеть какие то примеры, потому что на словах это все просто, создай сервис, добавь репозиторий, там же наблюдателей. Но на практике, без опыта - это не просто
  • Вопрос задан
  • 386 просмотров
Пригласить эксперта
Ответы на вопрос 2
inoise
@inoise Куратор тега PHP
Solution Architect, AWS Certified, Serverless
Бизнес-логика приложения в компоненты, имплементации в контроллерах, а модели должны быть максимально тонкими. В моделях единственная логика это behavior в виде timestamp, slug,...
Ответ написан
bitniks
@bitniks
Go/PHP/Symfony developer
Бизнес логику лучше вынести в сервисы. Каждый сервис должен заниматься какими-то своими задачами. Например, один работает с заказами, другой отправляет уведомления. Насколько сервис будет общий или наоборот конкретный, решать вам. Сервисы можно связывать между собой наследованием, агрегацией, композицией (перечислил в порядке от сильной связи до слабой). Чтобы не ломать голову, можно применять уже готовые шаблоны проектирования.

Изменился статус заказа, нужно отправить уведомления на почту, телеграм и тп. Записать в историю изменения суммы заказа, статуса.

Здесь напрашивается применение шаблона проектирования Наблюдатель. На изменение статуса создается событие, которое получают все подписчики.

Обновить/удалить кэш или обновить индекс в elasticSearch

Здесь я бы подумал на счет использования паттерна Декоратор

Думаю я не первый кто этим вопросом задался, и уже есть какие то архитектурные решения

Да, типовые решения уже есть, нужно просто изучить и попробовать на практике для своих задач

Хотелось бы увидеть какие то примеры, потому что на словах это все просто, создай сервис, добавь репозиторий, там же наблюдателей

На счет проектов не знаю, можно, наверное, просто поискать на github интересующее. Применение паттернов с примерами хорошо описано здесь https://refactoring.guru/ru/design-patterns/catalog
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы