Практики разделения на модули и микросервисы

Супер) Стримы вообще полезная тема. Можно даже попробовать взять чью-то предметную область и собрать участников на доске. И пусть попробуют сами добавлять стикеры)

Подскажите, этот стрим будет доступен в записи для подписчиков? Или именно эту запись нужно будет покупать отдельно?

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

О дате стрима сообщу в телеграме и рассылке.

Спасибо за первую часть стрима, может в будущем есть смысл альтернативный интернет иметь под рукой.

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

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

Спасибо!

Был бы интереснен такой кейс. Например есть заказ с позициями заказа. И в UI есть некоторое количество галочек (checkbox), типа - "Включить заказ в таможенную статистику" или - "Отслеживать кол-во упаковки в заказе" или - "Добавить адрес доставки на карту" т.е. какие-то действия, которые можно сделать с заказом "потом", но которые не являются частью модуля "Заказ".

Т.е. "Включить в таможенную статистику" должен получить позиции заказа, сгруппировать их ТНВЭД коды, и сделать какой-то отчёт для таможни. Т.е. это самостоятельное действие, где позиции заказа являются источником данных.

Тоже самое и "Отслеживать кол-во упаковки" - это действие должно получить информацию о позициях заказа, потом получить информацию как заказ упакован (картон, стекло, аллюминий, пластик) и так же сформировать какие-то данные на этой основе, которые будут например в какой-то определенном отчёте использоваться (например годовой расход такой-то упаковки).

"Добавить адрес доставки на карту" - собственно понятно что делает, но тут вопрос именно в том, что создатель заказа решает, надо его добавлять или нет. И этот флажок тоже не является частью домена "Заказ".

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

Вопрос в том, что все эти флажки - не являются частью доменной модели заказа, и их количество неограничено.

Т.е. интересно вот что: - как в UI добавляются эти флажки. Такие бизнес требования могут добавляться с течением времени, и не хотелось бы их хардкодить. Т.е. просто к сущности Заказ можно навешивать какие-то дополнительные действия, где сам заказ является источником данных. Флажки - это для примера банальные checkbox в UI - как передавать эти флажки в команду и как их обрабатывать в command handler - как дать знать тем объектам-обработчикам, что заказ надо ещё так-то и так-то процессировать. Понятно, что можно выкинуть событие OrderCreated, но эти флажки же не являются частью доменной модели "Заказ".

Надеюсь понятно объяснил :)

Спасибо.

Добрый вечер.

Вчера Вы сказали, что можно прислать примеры legacy кода для примера. Выслал Вам на почту пару маленьких архивов, приложил текстовые файлы с описанием как работает кода. Надеюсь, что он пригодится на повторном стриме и Вы дадите рекомендации как правильно работать с очередями и rabbitmq.

Добрый вечер. Прошу прощения, что объемно вышло.

1) Сервисный слой возвращает избыточные данные

Условный кейс Сервисный слой возвращает массив dto|entity в контроллер. В response же должны попасть только часть полей. Где лучше разруливать этот процесс, исключая ненужные поля ? 1. В контроллере перед ответом пробегаться по всем dto и формировать из них ассоциативные массивы из нужных полей ? 2. Создать аналогичный класс dto, за исключением ненужных полей. И где то в сервисном слое написать метод, который будет перебрасывать из дто одного типа нужные поля в дто второго типа. А далее контроллер будет сразу отдавать эти дтошки, внутри которых будут только нужные данные 3. Может еще какие то варианты ...

2) Данные из разных модулей сформировать в структуру единого ответа

Условный кейс Есть модуль скиллов. Оттуда мы получаем вложенное дерево дтошек SkillDto. Есть модуль юзеров. Оттуда мы получаем массив дтошек юзеров UserDto. Есть модуль прогресса. Оттуда мы получаем массив дтошек прогрессов ProgressDto. Прогресс имеет связь с одним юзером и одним скиллом.

Для ответа на фронт нам необходимо отдать следующую структуру, как пример [

skillDto1 => [
    skillDto2 => [
        SkillDto3 => [
            UserDto1 => ProgressDto1,
            UserDto2 => ProgressDto2,
        ]
    ]
],
skillDto4 => [
    skillDto5 => [
        UserDto1 => ProgressDto3,
        UserDto2 => ProgressDto4,
    ]
], ...

]

Т.о. нам необходимо создать иерархическую структуру, включающую в себя комбинацию списков сущностей 3 разных модулей.

Какие тут наиболее удобные и наименее болезненные варианты ? 1. Дать одному модулю из 3 (например модулю прогресса) выстраивать эту иерархию ? Отдельно получить массив скиллов, юзеров, закинуть какому-нибудь сервисному классу прогресса в метод эти 2 массива, а он добавит к этому массив прогрессов, сформирует из всех 3 типов данных требуемую структуру и вернет 2. В контроллере отдельно получить массивы скиллов, юзеров, прогрессов, далее прямо в нем же сформировать требуемую иерархию. Из минусов, если требуется эту структуру отдавать не только на этом эндпойнте, но и в других местах, придется дублировать код формирования этой структуры 3. Может еще какие то варианты ...

3) Создание записи в одном модуле требует создание в другом

Условный кейс Есть модуль прогресса. Там есть сущность progress и сущность progress_log. Первое - текущий прогресс. Второе - история изменений прогресса. Есть модуль активности. Там есть сущность activity. Это - активность, выполненная для получения прогресса.

progress имеет связь с одним progress_log. А progress_log имеет связь с одной activity.

Когда создается progress, вместе с ним создаются progress_log и activity. Причем в progress_log необходимо сохранить связь с activity (activity_id), поэтому вначале необходимо создать activity, вернуть ее инкрементный ID и уже потом создать progress_log с этим activity_id. В обратную сторону аналогично, когда создается activity, то вместе с этим создаются progress_log и progress, а в этот progress_log пробрасывается ее ID.

Как тут лучше ? 1. Разруливать все эти процессы и их очередность на уровне контроллера, дергая например сначала создание activity, потом progress_log, потом progress. 2. Разруливать это все на уровне событий и слушателей. Например создаем progress, отправляем событие о создании. На событие вешается обработчик, который создает activity и progress_log (которые правда сущности разных модулей, а создаются одним обработчиком) 3. Может еще какие то варианты ...

4) Обработка событий нужна не во всех случаях Условный кейс. Есть модуль прогресса. Есть модуль активности.

Допустим у нас есть метод создания прогрееса, где мы кидаем событие ProgressCreated. На это событие навешивается слушатель и создает каждому прогрессу активность.

В какой то момент нам становится необходимо в одном из участков логики создавать прогресс без активности. 1. Создавать аналог метода создания прогресса, но который не будет кидать событие ProgressCreated ? 2. Просто убрать с этого события слушателя, который создавал активность и разруливать дальше все создания аткивностей не событийным способом ? 3. Оставить событие и слушателя, но передавать в событие параметр, типа isActivityMustBeCreated ? 4. Может еще какие то варианты ...

Надеюсь примерно понятна суть сложностей. Просьба по возможности затронуть подобные вопросы) Спасибо!

Как организованы query-запросы между модулями? Чтобы не инжектить хендлеры одних модулей в другие. Прямо сетевыми http-запросами? или через QueryBus и последующий разбор $envelope? или как-то еще?

Стрим доступен всем?

1. Почему Вы полноценно не используете CommandBus и QueryBus ($this->commandBus->dispatch($command)), чтобы в нём уже запускать Validator ваших DTO. Вместо этого Вы напрямую вызываете $this->validator->validate($command) и $this->handler->handle($command). Из-за этого возникает постоянная необходимость в EventHandler, Action добавлять всегда две зависимости: Handler и Validator.
2. Вопрос уже задавал по событиям, но ещё раз акцентирую своё внимание к интеграционным событиям. 2.1 У Вас все доменные события являются интеграционными. Как в таком случае поступать с изменением структуры событий? Завтра поменяется поле в сущности или роль Пользователя станет массивом, то нарушится контракт события. Придётся всем доменным событиям всегда применять версионирование, потому что мы не всегда можем знать есть ли слушатель у нашего события или нет... 2.2 Что если нам нужно в доменные события добавлять дополнительную информацию, которую мы не можем взять из нашего Агрегата, а можем взять только из соседнего агрегата? 2.3 Что если нам нужно публиковать событие по условию, которое можем узнать только сделав запрос в базу. Например, при создании пользователя нам нужно отправить событие о регистрации каждого 1000-го пользователя. На это событие подпишется какой-то сервис подарков и выдаст бесплатную подписку на 1 год. 2.4 Если мы настроим какой-то импорт пользователей из сторонней системы, то у нас будет куча событий о добавлении пользователей. Теперь, чтобы в сервисе статистики поменять количество пользователей мне нужно слушать каждый раз событие о добавлении, вместо того чтобы отправить одно событие, что импортировано 10 000 пользователей, которое в сервисе статистики добавит к имеющемуся числу 10 000, вместо того, чтобы каждый раз увеличивать число на +1 и так 10 000 раз. Пример условный и упрощенный.
3. Если какие-то события имеют ошибку, которая поправима только после релиза новой версии, то нам надо отложить события в очередь failture, а после исправления ошибки снова опубликовать в основную очередь. Или другая политика ретраев. Как в этом случае быть? Например, у Symfony такое реализовано.
4. Чтобы в тестах везде не делать $user->realizeEvents() можно отказаться от DoctrineSubscriber и сохранять в EventStore события из нашего Flusher. Для этого Flusher сделать в виде интерфейса FlusherInterface и сделать разные реализации DoctrineFlusher, EventFlusher, AllFlusher и т д. Теперь избавляемся от подписчика и для прода используем FlusherInterface::class => new AllFlusher([DoctrineFlusher::class, EventFlusher::class]), а для тестов FlusherInterface::class => DoctrineFlusher::class. И в тестах менять ничего не придётся. А так получается очень странно, что мы из-за какого-то доктриновского подписчика будем переписывать все тесты добавляя в каждый тест $user->realizeEvents(). Представим что у нас уже готовый проект и много тестов. Выглядит не очень...
5. Будете ли реализовывать оптимистическую блокировку? Там есть проблема с вложенными сущностями. Приходиться добавлять агрерирующее поле. Решил добавлением поля aggregeteVersion.

Эх, Дмитрий уже не тот. Где фирменное рисование схем символами в ide?

Добрый день! Хочу прояснить, правильно ли понял все по поводу модульного монолита. На проекте выделено три модуля: - Заказы - Товары - API (api gateway)

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

1) Запрос клиента "Создай заказ" поступает на модуль API. 2) Модуль API получает нужные данные из модуля "Товары" 3) Модуль API вызывает команду "Создай заказ" модуля "Заказы"

Все ли верно ?

Дмитрий, почему бы вам не попробовать для рисования схем использовать опен сурсный https://excalidraw.com/