Максим Федоров

Фабрика сделана правильно, но нужно смотреть код где она используется. Поскольку Ваша фабрика отвечает за создание нескольких разных объектов есть риск нарушения принципа разделения интерфейсов

Тут важно понимать является ли запись в БД и Redis обязательной в процедуре обработки запроса ботом. Если она обязательна - тогда просто нужно сделать Ваши модули зависимыми (как это лучше сделать это уже другой вопрос). Если же нет тогда стоит использовать паттерн Observer, т.е.
в процессе обработки должны создаваться разные типы события а остальные модули должны на них подписываться и обрабатывать.

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

Возьмем например Ваш объект репозитория, его достаточно зарегистрировать в контейнере так

Yii::$container->setSingleton('common\domain\Entities\User\Profile\Interfaces\Repository', // указываем интерфейс
    [ // указываем конфигурацию класса реализующего этот интерфейс
        'class' => 'common\infrastructure\Entities\User\Profile\Repository' 
    ], 
    [ // указываем какие данные необходимо передать в конструктор, в частности - экземпляр класса UserProfile
        Instance::of('common\models\ActiveRecord\UserProfile')
    ]
);

Контейнер соответственно сам проинжектит в объекты использующие common\domain\Entities\User\Profile\Interfaces\Repository объект common\infrastructure\Entities\User\Profile\Repository

Сервис регистрируется аналогично:

Yii::$container->setSingleton('common\domain\Entities\User\Profile\Interfaces\Service',
    [
        'class' => 'common\application\User\Profile\Service',
    ],
    [
        Instance::of('common\domain\Entities\User\Profile\Interfaces\Repository')
    ],
);

При создании сервиса, контейнер найден в своих данных объект соответствующий common\domain\Entities\User\Profile\Interfaces\Repository создаст его и проинжектит в сервис

Reciver - Содержит в себе набор некой функциональности
Command - Содержит в себе алгоритм реализации определенного действия, с помощью использования функциональности заложенной в Reciver
Client - Знает как создать команду и какой Reciver ей подсунуть
Invoker - Выполняет конкретную команду

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

Во первых не всегда бывает что команда вызывается там где создается. Во вторых Invoker содержит механизмы выполнения всех команд, т.е. в нем например может быть форматирование результата выполнения команд и прочие действия связанные с выполнением ВСЕХ команд приложения.

по сути набор предопределенных алгоритмов с общим интерфейсом

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

Возьмем для примера билдер:

class Builder {

	protected $obj;

	public function create(){
		$this->obj = new HtmlDocument();
	}
	
	public function addHeader(){
		// добавляем хедер в $this->obj
	}
	
	public function addFooter(){
		// добавляем футер в $this->obj
	}
	
	public function getObj(){
		return $this->obj;
	}
}

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

А теперь давайте возьмем стратегию:

interface CalculateDiscountInterface {

	public function execute($price);
}

class ClientCalculateDiscount implements CalculateDiscountInterface {

	public function execute($price){
		// рассчитываем цену по одному алгоритму
	}
}

class ParterCalculateDiscount implements CalculateDiscountInterface {

	public function execute($price){
		// рассчитываем цену по другому алгоритму
	}
}

Какое назначение стратегии? Реализация одной и той же функциональности по разным алгоритмам, с возможностью замены друг другом.