Бизнес логику лучше вынести в сервисы. Каждый сервис должен заниматься какими-то своими задачами. Например, один работает с заказами, другой отправляет уведомления. Насколько сервис будет общий или наоборот конкретный, решать вам. Сервисы можно связывать между собой наследованием, агрегацией, композицией (перечислил в порядке от сильной связи до слабой). Чтобы не ломать голову, можно применять уже готовые шаблоны проектирования.
Изменился статус заказа, нужно отправить уведомления на почту, телеграм и тп. Записать в историю изменения суммы заказа, статуса.
Здесь напрашивается применение шаблона проектирования Наблюдатель. На изменение статуса создается событие, которое получают все подписчики.
Обновить/удалить кэш или обновить индекс в elasticSearch
Здесь я бы подумал на счет использования паттерна Декоратор
Думаю я не первый кто этим вопросом задался, и уже есть какие то архитектурные решения
Да, типовые решения уже есть, нужно просто изучить и попробовать на практике для своих задач
Хотелось бы увидеть какие то примеры, потому что на словах это все просто, создай сервис, добавь репозиторий, там же наблюдателей
На счет проектов не знаю, можно, наверное, просто поискать на github интересующее. Применение паттернов с примерами хорошо описано здесь
https://refactoring.guru/ru/design-patterns/catalog 
