Как уже выше написали, всю бизнес логику лучше разместить на уровне модели, а контроллер оставить "тонким". Чтобы не нарушать принцип единственной ответственности, можно использовать паттерн Наблюдатель. Модель после добавления товара будет создавать событие, на которое смогут подписаться другие компоненты приложения. В результате код, ответственный за разные действия, будет находится в разных сервисах системы, и при этом слабо связан между собой

Совет прочитать роберт мартин чистая архитектура Хотя бы главу о SRP Обратить внимание "Мартин определяет ответственность как причину изменения и заключает, что классы должны иметь одну и только одну причину для изменений." Обратить внимание когда допускается все оставить в одном классе и когда желательно разделить класс. Пока мало опыта разбивать на слои как в примерах чистой архитектуры (в интернете достаточно) Или набивать шишки и думать почему я не сделала так как это было в примерах) Помнить цель солид очень прагматична - сделать код который легко сопровождается. Всегда об этом помнить.

Принцип единой ответственности не означает реализацию в виде одного действия или одной строчки кода. метод add добавляет, что он еще там вызывает - не суть важно. главное конечная цель. остальное - лишь вспомогательные механизмы, которые если нужны для добавления - то никто не запрещает их использовать.