Пётр Грибанов

У меня есть опыт такого подхода.

Symfony это фреймворк который состоит из набора компонентов и интеграционного слоя. Symfony выделяет отдельные компоненты в отдельные репозитории для того, чтобы их можно было использовать независимо от фреймворка.

Не думаю что у вас есть в это особая необходимость. Но вы можете разработать какие-то свои компоненты и вынести их в отдельные репозитории и устанавливать как зависимости. Можно даже сделать их open source и сообщество может вам помогать в их разработке и сопровождении.

Как и сказал BoShurik, бандл это уровень интеграции компанента в фрайморк. Выделяя компонент в отдельный репозиторий вам нужно и бандл выделять в отдельный репозиторий. Так у вас будет 2 отдельных git репозитория.

Таким образом у вас будет следующие git репозитоии:
- ядро проекта
- компонент блога
- бандл блога
- компонент мероприятий
- бандл мероприятий
- компонент деятелей
- бандл деятелей
- компонент аккаунта
- бандл аккаунта
и др. х2

Разделение проекта на много независимых репозиториев это не есть плохо. Как и разделение проекта на микросервисы. Но у этого подхода есть существенный недостаток. Часто нужно внедрять новые фичи или править баги которые требуют внесения изменений в несколько репозиториев одновременно. Это доставляет массу неудобств. Особенно когда нужно проходить через этап релиза. Протестировать в проекте работу правок можно только после внесения их в бандл и релизе его, а зарелизить бандл можно только после его тестирования, а тестирование бандла требует тестирования и релиза компонента, а делать релиз компонента не убедившись как оно будет работать в конечном продукте нельзя. В общем релизный ад. Я проходил через него и не советую другим. Это осмысленно только для больших проектов с большой командой разработчиков.

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

App/Blog/Controller
App/Blog/Entity
App/Events/Controller
App/Events/Entity

Разработчики Symfony зря советуют не использовать бандлы. Ваши модули по сути и будут бандлы. Вы создаёте в модуле бандл в котором описываете метод интеграции модуля с фреймворком.

App/Blog/AppBlogBundle
App/Events/AppEventsBundle

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

Касательно того как всё устроено конкретно в Symfony. Я довольно давно изучал этот вопрос и могу ошибаться в деталях.
В Symfony когда-то использовался git submodules для компонентов. Но от этого решения отказались. Оно не очень удобное, особенно для конечного пользователя. В плане разработки это чуть удобнее чем отдельные пакеты на мой взгляд.
Сейчас всё работает иначе. Есть основной репозиторий symfony/symfony. Все компоненты находятся в нем. Всё правки вносятся в него. В репозиториях компонентов никакой активности нет. При коммитете или пуше в ветки symfony/symfony запускается хук который на отдельном сервере SensioLabs запускается специальная утилита которая копирует все коммиты сделанные в компонентах из symfony/symfony в репозитории соответствующих компонентов. Мне как-то попадался сайт SensioLabs на котором можно было скачать эту утилиту.
Суть в том, что это не репозиторий Symfony состоит из репозиториев компонентов. Это компоненты Symfony по сути выдранные куски кода из основного репозитория.

Я когда-то тоже хотел сделать приложение с выделенными модулями в отдельные репозитории как у Symfony, но разобравшись в вопросе я пришел к выводу, что мне это не подходит. И вам думаю тоже не подойдёт.

Для начала рекомендую глянуть библиотеку для реализации доменных событий
https://github.com/gpslab/domain-event

Еще рекомендую определится с терминологией. "Покупка лучшего фильма", "Лучшие фильмы" и "Покупка фильма" это не домены, а ограниченные контексты (Bounded Context).

Не может быть агрегата уровнем выше. У вас неправильное понимание термина Агрегат. И с доменными событиями тоже самое. Доменные события должны бросаться в сущностях, а не сервисах прикладного уровня.

Далее. Вы списываете баланс со счета пользователя, потом выдаёте ему доступ к фильму и потом бросаете событие и все это делаете последовательно, да ещё и заварачиваете в БД транзакцию, хотя это бизнес транзакция.

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

И все же вернёмся к вашей проблеме.
> пользователь может подписаться на услугу "Дайте мне доступ к лучшему фильму недели"

Вы явно описали понятие Услуга. И у вас есть две, скажем так, услуги:
- Лучшие фильмы недели
- Покупка одного фильма

Отсюда у вас появляется:

interface Service
{
    public function price(): Money;

    // ...
}

class OneFilmService implements Service
{
    public function __construct(Film $film)
    {
        // ...
    }

   // ...
}

class BestFilmsService implements Service
{
    // ...
}

class User
{
   // ...

    public function buyService(
        AccountRepository $repository,
        Service $service
    ) {
        // получаем текущий счёт пользователя
        // и выполняем покупку
        $repository
            ->get($this->id)
            ->buy($service->price())
        ;

        // добавляем пользователю
        // преобретенную услугу
        $this->services[] = $service;

        // бросаем доменное событие
        $this->raise(new ServicePurchased(
            $this->id,
            $service->id()
        );
    }
}

Простой и наглядный способ покупки услуги.

Получение денег от клиента по средствам СМС инкапсулированно в UserAccount.

Если между покупкой и получением доступа к услуге должно пройти несколько минут, можно ввести понятие -
Активация заказанной услуги.

То есть, пользователь покупает/заказывает услугу и возможно даже видит ее в своём личном кабинете, но активация услуги и соответственно доступ к ней выполняется только после поступления средств от клиента через СМС или ещё как.