Вопрос как вы следуете подходу Clean architecture в гошных сервисах. По

феншую это когда useCases не знают детали реализации репозиториев и просто обращаются по интерфейсу.
Например есть UserRepository интерфейс, есть его имплементация в PostgreSQL, в usecases в конструкторе инджектим интерфейс репозитория и вуаля, доменный слой не обращается к инфраструктуре.

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

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

Оно? https://github.com/dimuska139/go-api-layout/blob/master/internal/services/shrink.go#L30

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

Т.е. usecase собирает доменную сущность?

да

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

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

А чего говорить, ты ссылку на гитхаб кидай

я помню что обещал ( нет времени сейчас

Есть такое дело, согласен

Если вы хотите транзакции в usecases, то у вас протекли абстракции

бизнес транзакции

да, раскройте мысль пожалуйста, как их юзать без протечек

лично я сейчас юзаю транзакции только на уровне репозитория а на уровне usecase у меня бизнес транзакции с ручным роллбеком (то есть я не пользуюсь транзакциями в БД в данных кейсах)

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

Это кто сказал?

в спринге transactional пишут над функциями сервиса?

usecase и над сервисами, да

почему? Сервис же не имеет отношения к бд нижележащей, а transactional пишется все же над сервисом.

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

https://github.com/dikkini/askyourday/blob/master/src/main/java/com/askyourday/service/YetUserDetailsServiceImpl.java