What should be the application architecture without ActiveRecord in Yii2?

Question

PHP

Here we quickly created a project on AR (ActeveRecord) requests through it, recording and updating. To start a new project, I think this is quite normal, despite the fact that the project may not take off.
But the project lives on, AR models swell with logic. The database is growing, along with the volume of processed information. And you already need to think about how to take the logic out of AR (behaviors, AfterSave, BeforeSave) in the first place, so that it can be applied with batchInsert and batchUpdate.
A small digression, about the logic, examples:

• The status of the order has changed, you need to send notifications by mail, telegram, etc. Record in the history of changes in the amount of the order, status.
  
• Update/delete cache or update index in elasticSearch
  
• Submit data for moderation
  
• And everything like that
  

---
There are thoughts that you need to put all this into handlers and events, for example, some class processes changed data (compares old data with new ones) and creates events, and the execution of actions on events should be processed somewhere in the queue, separately, so that the current task for batchInsert and batchUpdate in several thousand records is not slowed down.
But how should it look architecturally, what are the nuances and pitfalls?
I think I'm not the first who asked this question, and there are already some architectural solutions.
I would like to see some examples, because in words it's all simple, create a service, add a repository, observers in the same place. But in practice, without experience, it's not easy

Answer 1

Application business logic in components, implementation in controllers, and models should be as thin as possible. In models, the only logic is behavior in the form of timestamp, slug,...

Answer 2

Business logic is better to take out in services. Each service should deal with some of its tasks. For example, one works with orders, the other sends notifications. How the service will be general or vice versa specific is up to you. Services can be linked together by inheritance, aggregation, composition (listed in order from strong to weak). In order not to rack your brains, you can use ready-made design patterns.
This is where the Observer design pattern comes into play. An event is created for a status change, which is received by all subscribers.
Here I would think about using the Decorator pattern
Yes, there are already standard solutions, you just need to study and try in practice for your tasks.
I don’t know about projects, you can probably just search on github for what you are interested in. The use of patterns with examples is well described here https://refactoring.guru/en/design-patterns/catalog