Для меня репозиторий это

type UserRepository interface {
        FindAll() ([]*model.User, error)
        FindByEmail(email string) (*model.User, error)
        Save(*model.User) error
}

Если нужны распределенные транзакции между репозиториями, то пришлось бы заморочиться. но sql.Tx я бы не вытаскивал наружу. Пусть будет много транзакций, переживем. Потому что репозиторий - абстракция, в которой сокрыто как хранятся данные. Тайна за семью замками. Когда реализация вылезает снаружи, становится сложно поддерживать. Но это чисто мои теоретические рассуждения. Такие задачи не приходилось реализовывать.

type UserRepository interface {
        FindAll() ([]*model.User, error)
        FindByEmail(email string) (*model.User, error)
        Save(*model.User) error
}

лучше plural:

FindByEmail(emails []string) ([]*model.User, error)

оптимизировать обычно легче

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

type UserRepository interface {
        FindAll() ([]*model.User, error)
        FindByEmail(email string) (*model.User, error)
        Save(*model.User) error
}

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

+ мы же каждый день переезжаем из mysql в postgres и обратно) конечно для легких сервисов не нужно все усложнять, согласен

type UserRepository interface {
        FindAll() ([]*model.User, error)
        FindByEmail(email string) (*model.User, error)
        Save(*model.User) error
}

ах да, и про context.Context не забываем)

спасибо, учту

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

транзакция = неделимая единица работы = метод.

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

Складывается ощущение, что существует какое то когнитивное искажение, подкрепленное кучей неудачных примеров из категории: "А что если мы заменим БД?". Идея отделения Бизнес-Сущностей от БД никогда не преследовала цель замены БД как таковую. Это скорее сайд эффект, но ни как не основная цель данного разделения.

Да даже если у вас несколько баз, это все равно можно скрыть за одним DAO/Gateway

лёгкость или сложность сервиса по-моему значения не имеет. У меня и для лёгких и для сложных сервисов используются репозитории двух реализации - кеш и дб. Из бизнес логики работаю с кешом. При этом кэш - адаптер над бд. При получении данных кеш смотрит данные у себя - если есть выдает. Если нет - лезет в бд и кеширует в себя. Если идёт изменение данных кеш сразу дергает бд, затем инвалидирует данные у себя.
При этом для части данных кеш ин мемори, для части распределенный - редис, эластик.
А вы говорите "используйте" sql.db 😂

ну ты чего, завтра ж заменим БД )

Бывали и такие кейсы 🙂

Никто от метода не отказывается. Вопрос в том, это метод какой сущности

естественно бывали ) но не у каждого третьего )

БД вряд ли заменим 🙂  (Хотя если выстрелит, может и такое случиться, пусть и 1 раз в 5 лет), а вот бизнес-логику заменим 100% и будем ее менять на протяжении всей жизни проекта (Еженедельно а то и чаще)... Вот тут и стоит задуматься: А зачем отделять бизнес-логику от инфраструктуры?

Создавать новую сущность)

если у нас Order и User связаны в некой транзакции - они часть одной сущности / одного интерфейса

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