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

тупо плюсую. ребята думают что вообще всю логику надо дико изолировать потому-что она "переиспользуемая" - хаха )

переиспользуемое на гитхабе в опенсорсе лежит) все остальное одноразовое

"если для этого документооборота нам понадобился event sourcing то наверное профиль юзера так же надо..."

Ыыы ))

Слышал 2 версии как запрашивать данные которые агрегируются через left join если монолит.

Первая. Мы передаем ид только нужных строк и потом из второго микросервиса достаем нужные нам данные. Например отсылка письма. Передаем ид человека а потом сервис запрашивает все нужные данные для формирования письма у другого микро или даже первого если там ему южные данные лежат.

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

Так ли это и как вы бы разрулили эти ситуации ?

Ребята, позвали на работу где используется Spryker (PHP). Кто-то работал с этим?

Второй вариант и вот эти синхронизации данных обычно приводят к проблемам. Я за первый вариант ui composition и вот это все

Не тот чат

Ребята, подскажите, когда я пишу Unit тесты, получается так, что на класс с парочкой методов, в которых по 5-10 строк кода, у меня получается класс теста, на 400-500 строк кода, в котором 90% это создание моков, а тестирование контракта и иногда логики это процентов 5-10% кода теста. Спустя время, такие тесты очень тяжело читать, это нормально или сигнал проблемы?

сигнал проблемы. но да, такое нередко.

Мне он тоже более понятлив и регулируемый. При помощи messenger агрегацию  данных с разных микррсервисов производить можно? И если как то как это делается?

Не нормально

Возможно, у класса слишком много зависимостей, или сами зависимости слишком большие

symfony/messenger не про request/response

Ну если запустить слушатель на обоих концах и посылать по шине данные то можно также сделать я думаю. Нет ?

Ну вот например тест ларовского котроллера с одним методом. В него инжектится репозиторий какой-то нить сущности, диспатчер очередей и какой-нить сервис. Пишем тест, замокать надо

- репозиторий
- коллекцию что он возвращает
- сущности внутри коллекции
- диспатчер
- серврис + его связанные сущности

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

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

дробить его еще больше?

Я такие вещи не тестировал бы юнитами