ну при желании их можно называть хоть одинаково, но положить в разные пакеты

Ну не это уже не оч как то, лучше разные суффиксы, на мой взгляд. Типа EventMessageDto для брокера и EventDto для сервиса

если туда уходит дто, то веб слой завязан на бизнес логике,
отправлять в сервис дто, проще тем что кода меньше будет,
но там есть отдельный паттерн для этого "Service Facade Pattern" но когда будет больше.

нравиться такое решение, идеально

но насчёт суффиксов всё таки подумай)

спасибо, решение нравиться

Запутаешься потом

какой может быть суффикс? @romanboyara предложил вариант ProductEventDto, ProductMessageEventDto

можно использовать два дто, одно для веба а одно для бизнес-логики, не знаю правда есть ли в этом смысле если не используется jpa

я над этим вопросом сидел как-то, у людей мнение сильно расходится и вот решение этот паттерн "Service Facade Pattern",
по сути еще один слой, который просто занимается трансформацией и логгированием данных, приход / уход данных,
легче работать с service, если там только entity и ничего что связано с web,
меньше код будет ломаться, но честно кода так будет намного больше, эти конвертеры для небольшого проекта думаю оверхед.

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

дто это не только отображение для веба - это для любого приведения данных к определённому формату
https://www.petrikainulainen.net/software-development/design/understanding-spring-web-application-architecture-the-classic-way/

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

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

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

я с вами полностью согласен, спасибо вам за помощь.

Вы когда отправляете domain event сообщение через брокер,
вы указываете какие-нибудь еще данные?
Например: aggregateType, aggregateId, Type, Payload.

просто установил пакет kafka и не вижу возможности добавить подобные поля,
если бы у меня был бы cqrs+event sourcing, то мне это точно понадобилось бы.

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

пример отправки сообщения из книжки (microservices patterns):
eventPublisher.publish(Order.class, Long.toString(order.getld()), orderAndEvents.events);

картинка с примером: https://debezium.io/images/outbox_pattern.png
—-
знаю что есть еще фрейморк для этого axoniq, но не приходилось использовать.

Hello guys подскажите пожалуйста какой-то канал с работой для джава девелоперов

Описание чата читать не пробовала?

Как в спринге сеттать хедер на все запросы к  другим сервисам?

как угодно

В описане чата

Thank you

Всем салют
Столкнулся с проблемой получения коллекции из кеша
При сохранении сущности

simpleEntityRepository.save(simpleEntity); // сохраняется в базу и в кеш L2

При получении этой же сущности по id

simpleEntityRepository.findById(simpleEntityId); // читается из кеша L2, никаких запросов к БД

Но когда внутри сущности есть коллекция, то она не читается из кеша, а берется отдельным запросом из БД - почему ?
github
spring boot последний, spring-data-jpa, hibernate, ehcache