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

Question

[RusMits]

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

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

Небольшое отступление, по поводу логики, примеры:

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

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

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

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

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

Comments

[Вадим Косолапов]

https://github.com/k0v4back/Board-on-yii2 - использовал сервисы, сущности и репозитории. Может будет полезно посмотреть.

Answer 1

[Иван Шумов]

Бизнес-логика приложения в компоненты, имплементации в контроллерах, а модели должны быть максимально тонкими. В моделях единственная логика это behavior в виде timestamp, slug,...

Comments

[RusMits]

Но как это выглядит на практике, вот прям бы пример.
Пользователь редактирует данные магазина, или заказчик отменил заказ или админ отменил заказа, стоимость заказ поменялась. Каждое из этих действий имеет свою логику, у каждого действия несколько событий для других объектов. И как это все оформляется в коде архитектурно?

То есть под каждое действие нужно отдельные компоненты/сервисы делать или один сервис занимается обработкой редактирования одного объекта. Для админа и для пользователя два сервиса или один - так как логика тоже может отличаться.
Что если одним POST запросом редактируется несколько объектов, один сервис работает с двумя сервисами для разных объектов или из контроллера идет управление сервисами или один сервис работает с другим сервисом.

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

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

[Иван Шумов]

RusMits, разделяйте действия в системы м процесс изменения данных. Компоненты БЛ могут быть независимыми, могут даже наследовать друг-друга. В идеале контроллер это точка входа где входящий запрос фильтруется и при успехе трансформируется в формат, пригодный для компоненты БЛ. Таким образом вы можете переиспользовать их.

Почитайте про SOLID. Он не только для кода

[RusMits]

Для статы отвечаешь?
Твои абстрактные ответы бесполезны, в вопроса где спрашивают про практику

[Иван Шумов]

RusMits, любая нормальная практика основана на теории. Не поверишь сколько я от этого бегал и не ценил) вот, исправился и другим рекомендую

[Евгений Ромашкан]

Анемичная модель - антипаттерн.

[Евгений Ромашкан]

RusMits, Жалкие попытки сделать что-то красиво на практике не читая теории тоже бесполезны.
Вы очень наивно полагаете что кто-то на тостере научит вас программировать.

[Иван Шумов]

Евгений Ромашкан, анемичная модель не считается анти-паттерном, но на самом деле это очень интересный шаблон проектирования. Просто работает не со всеми случаями

[Евгений Ромашкан]

Иван Шумов, Анемичная модель не считается антипиттерном в основном у тех кто не умеет модели проектировать чтобы там 20 полей не появлялось.
Остальное елси лишь в очень специфичных случаях которые автору не нужны

[Иван Шумов]

Евгений Ромашкан, останемся каждый на своем мнении. Число полей никак не относится к паттернам проектирования, а тот или иной подход зависит от проекта

Answer 2

[Евгений Самсонов]

Бизнес логику лучше вынести в сервисы. Каждый сервис должен заниматься какими-то своими задачами. Например, один работает с заказами, другой отправляет уведомления. Насколько сервис будет общий или наоборот конкретный, решать вам. Сервисы можно связывать между собой наследованием, агрегацией, композицией (перечислил в порядке от сильной связи до слабой). Чтобы не ломать голову, можно применять уже готовые шаблоны проектирования.

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

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

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

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

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

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

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

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

Comments

[Евгений Ромашкан]

Анемичная модель - антипаттерн.