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

Да, всё останется для участников

Ориентируюсь на 4..5 часов с небольшими перерывами и ответами на вопросы

Да, можно потом, но по возросшей цене.

Будет в скринкастах.

В 18:00 по московскому. Это уже отображается по местному.

Для всех будет интересен.

Нет, подписка приобретается отдельно в кабинете.

Попробуйте обновить страницу

Хочу поделиться своим мнением, пока нет ответа Дмитрия.

1. Внутри модуля Корзины добавляются только те данные, которые нужны именно ей. Id товара, цена, id покупателя, количество… Всё остальное запрашивается по Api/Query из других модулей.
2. Система скидок не относится к корзине - отдельный модуль, например Продажи. Так же и с ценообразованием. Ценообразование никак не влияет на корзину. У него даже другая терминология, единый язык. Если видите другой язык, не присущий этому модулю, то с большей вероятностью это другой модуль/контекст.
3. Делать денормализацию для Корзины из всех модулей не имеет никакого смысла. У вас появится куча событий, которые будут постоянно обновлять корзину из разных модулей. В этом тоже нет ничего хорошего.
4. Модуль Корзина проектируется исходя из требований. Например, эта же цена в корзине может быть зафиксирована в самом модуле, чтобы при изменении цен пользователь мог приобрести товар, по которой добавил в корзину. Либо цена может браться всегда из другого модуля по запросу. Т.е. зависит от требований.

В целом по этой теме есть интересный доклад, как раз рассматривается пример с корзиной: https://youtu.be/MotE7e30jGM

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

Обычно цены товаров нужно фиксировать только при заказе. В корзину их копировать нет смысла.

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

$aggregator = new ConfigAggregator([
   // ...
], __DIR__ . '/../var/cache/config-cache.php');

и в продакшеновской конфигурации включив опцию:

return [
    ConfigAggregator::ENABLE_CACHE => true,
]

Это будет экспортировать весь общий массив в файл, сэкономив нам время на загрузку и merge всех массивов.

Но любое такое кеширование не позволяет экспортировать анонимные функции вроде наших фабрик:

'factories'  => [
    UserRepository::class => static function (ContainerInterface $container): UserRepository {
        $em = $container->get(EntityManagerInterface::class);
        $repo = $em->getRepository(User::class);
        return new UserRepository($em, $repo);
    },
],

Чтобы это заработало нам нужно будет вынести эти фабрики в отдельные классы:

final class UserRepositoryDIFactory
{
    public function __invoke(ContainerInterface $container): UserRepository
    {
        $em = $container->get(EntityManagerInterface::class);
        $repo = $em->getRepository(User::class);
        return new UserRepository($em, $repo);
    }
}

и в конфигурации указать строками имена этих классов:

'factories'  => [
    UserRepository::class => UserRepositoryDIFactory::class,
],

Тогда у нас будет кэшируемая конфигурация в виде массива из строковых имён классов без анонимок.

++ тоже хотел бы посмотреть на такое

В следующем стриме про практики разделения как раз полностью реализовали работу с очередями по паттерну Transactional Outbox для хранения и передачи событий.

делать любые запросы с первого сервера на второй очень долго

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

чтобы записать ее в БД, мне не нужна доктрина

Да, для такой синхронизации ничего не нужно. Можно сделать отдельный модуль или сервис вроде ProductsSync.

а если создам, то надо как-то закрыть ее от использования в коде программистом

Можно сущность пометить аннотацией @internal и поместить в папку с сервисом. Тогда Psalm не разрешит вызывать её из других мест.

Мы вроде говорим о том, что модули не должны иметь прямых зависимостей от других модулей. При этом листенер из Newsletter прямо импортирует событие из модуля Auth. Тут бы и дептраку ругнуться самое время.

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

А в случае изолированного сервиса как вы себе это представляете?

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

{
    "name": "App\Auth\Event\UserSignedUp",
    "payload": {"id": 25, "email": "..."}
}

В случае же отдельных микросервисов в очередь сериализуют событие с текстовым именем вроде:

{
    "name": "auth.user_signed_up",
    "payload": {"id": 25, "email": "..."}
}

и другие сервисы его десериализуют в свои собственные DTO для каждого интересующего их события.

А в этом варианте получается у нас информация об одном событии и его структуре хранится в 100500-ста модулях... Согласованно в 100500 модулях внести изменение в классы ивентов, или какое-то версионирование изобретать для схемы данных ивента... Выглядит как-то громоздко

Верно. В случае микросервисов так и делают. Каждый сервис как отдельный проект в своей документации описывает своё API в виде схем HTTP-запросов и схем событий. И делают версионирование, если хотят что-то поменять.

Что если вынести события всех модулей в какой-то общий Common модуль, или Events или Contracts...

Любой такой общий пакет Common сразу станет большим и неудобным.

...который будут все сервисы так или иначе импортировать?

В случае микросервисов нужно учитывать, что разные сервисы могут быть написаны на разных языках программирования. Поэтому использовать имена классов и выносить в пакет и импортировать эти PHP-классы будет бесполезно.

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

В случае HTTP API можно описать схему в формате OpenAPI для Swagger и по ней через Swagger Codegen генерировать классы для каждого языка программирования. Также можно при необходимости сделать и для событий.

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

Зачем писать ForThisParticularFormFetcher, если можно написать CategoryFetcher::all($filter), и использовать его для любого функционала во фронтенде, где нужен список категорий?

Сомнение 1: они так разрастаются для каждого кейса в кучу таких фетчеров для каждого клиентского кейса и все в одном месте в модуле?

Они разрастутся независимо от того, в какую папку вы их положите. Хоть в сам модуль, хоть в Http.

Сомнение 2: наш чистый модуль с бизнес логикой знает про всякие специфичные для фронтенда юзкейсы. А должен ли он?

Как уже ответили выше, называйте фетчеры не по имени формы, а по тому, какая информация необходима.

Да, при переходе полностью на событийную работу будет удобнее именно так. При оплате в одном месте активируется доступ в других местах. Тогда внешние проверки не понадобятся.

Но в подходе, что вы описываете, и по ответам в комментариях мы все равно допускаем прямые зависимости (импорт классов) на события внутри модулей, мы вроде как через событийную шину запускаем команды - ок, но с другой стороны у нас в модулях есть набор Queries/Fetchers, которые напрямую импортируются и запускаются внутри слоя с контроллерами и т.д.

Все это наводит на размышления о том, что необходимо будет сделать, чтобы окончательно выделить модуль в сервис?

Потребуется перенести код самого модуля, дописать контроллеры и скопировать к себе классы событий.

Например, код микросервиса комментариев может оказаться таким:

src/

  // Вынесенный код модуля из проекта как есть:

  Comment/
    Command/...
    Entity/...
    Query/...
    Listener/...

  // Дописываем свои контроллеры, которые теперь будут вызывать Command и Query:
 
  Http/
    Action/
      IndexAction.php
      AddAction.php

  // Дублируем у себя классы чужих событий

  Auth/ 
    Event/
      UserSignedUp.php

  // Общая инфраструктура

  Queue/...
  Fetcher.php

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

В изначальном проекте, например, оставляем от модуля копии классов Command как есть и оставляем классы Fetcher, переписанные на хождение по сети к сервису.

Возможно нужен какой-то контракт, который бы был известен HTTP слою и по которому он мог бы обращаться к модулю. В каком виде? Это класс-интерфейс в случае если у нас всё на одном языке?

В случае написания модульного монолита на Java сам язык поддерживает модульность через конструкцию module. И в модуле можно объявить публичными нужные интерфейсы или классы и только они будут видны снаружи. Это могут быть либо отдельные классы, либо один большой класс-фасад со всеми методами.

В языке PHP такого нет. Поэтому приходится договариваться на словах или размечать через deptrack что кому доступно.

Так что в монолите да, можно опираться на публично доступные классы и интерфесы.

Если это интерфейс, то где должны жить реализации этих интерфейсов?
Ну тут уже совсем в какие-то дебри мысль уходит.

Да, это малополезные дебри. Когда надо будет вынести, тогда в монолите за минуту класс CommentFetcher переименуете в интерфейс и реализацию вынесете в LocalCommentFetcher. И тогда рядом напишете RemoteCommentFetcher, где вместо $this->db->query(...) будет $this->http->get(...). Потом переключите класс в конфигурации. И через день удалите старый класс и уже малополезный для одной реализации интерфейс.

Или какие-то универсальные стандарты описания в случае если нужно интеграцию сервисов на разных языках реализовывать?

Если что-то вынесено в отдельный микросервис, то теперь этот микросервис является полноценным отдельным сайтом, с которым теперь из нашего gateway или из любой саги нужно работать по HTTP API и через очередь.

То есть теперь мы со своим микросервисом работаем также, как работаем по API со Сбербанком или другим сервисом. У каждого микросервиса может быть документация с описанием всех JSON-запросов и ответов. Например, если нам нужно на свой сайт загрузить список мероприятий из Яндекс Афиши, то обычно мы в её документации для API находим описание запроса GetEvents и пишем свой класс DTO с нужными нам полями, на который теперь маппим этот ответ. Также можем и с микросервисами.

Про автогенерацию кода пока не знаю ничего.

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

Но чтобы не описывать все DTO вручную можем автоматизировать это автогенерацией. Например, при использовании API по протоколу gRPC сервис публикует свои proto-файлы со схемами вроде этих от Tinkoff Invest API. Аналогично с API по протоколу GraphQL сначала в особом формате описывается схема. Также REST API можно описать схему как в примере. И потом другие программисты по этим схемам могут автоматически генерировать все DTO для своего языка и потом через git diff смотреть, что там изменилось.

Я бы начал с исправления и обновления существующего кода как делал у себя, о чём рассказывал в докладе. А уже потом бы при необходимости постепенно выделял части. Если точно планируете распил на микросервисы, то может помочь книга "От монолита к микросервисам" Сэма Ньюмена. Там как раз про шаги и подходы.

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

Если есть возможность, то разбить долгие скрипты на короткие этапы.