Ну я если делаю слой абстракции для работы с определенной коллекцией, то называю типа PostRepo, CommentRepo, UserRepo. Ну интерфейсы например и реализация для конкретной БД например. Если не хочу заморачиваться делаю просто одну структуру, которая ходит в БД, сохраняет, что то удаляет и называю ее DB.

А что вы делаете, если вдруг у вас есть userRepo и commentRepo как и позже требуется выполнить некоторые операции из обоих репозиториев в одной транзакции?

Выносить транзакцию на уровень сервиса

Ну ок, а сами реализации как изменятся?

Читайте Вернона Implementing DDD...

Никак

Никак

То есть если зафейлит один из запросов, вы сделаете отмену как? Например, выше был запрос на создание ресурса, следующий запрос зафейлил, и вы сделаете запрос на удаление создания предыдущего ресурса?

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

Например:

post, err := controller.db.GetPostById(params.PostId)

 if err != nil {
  return result, errors.InternalError
 }

И логика обращения к кэшу скрыта в методе

GetPostById

, либо же

post, err := controller.cache.GetPostById(params.PostId)

 if err != nil || !post.Exists() {
  post, err = controller.db.GetPostById(params.PostId)
  if err != nil {
   return result, errors.InternalError
  }
 }

Явно показываем в юзкейсе, что обращаемся к кэшу

Создаёшь транзакцию на уровне сервиса, передаёшь её в оба репозитория, коммитишь в сервисе. Но вообще, если у тебя юзеры и комменты нужно в одной транзакции обрабатывать - ты уже не туда свернул раньше.

То есть если зафейлит один из запросов, вы сделаете отмену как? Например, выше был запрос на создание ресурса, следующий запрос зафейлил, и вы сделаете запрос на удаление создания предыдущего ресурса?

Создаёшь транзакцию на уровне сервиса, передаёшь её в оба репозитория, коммитишь в сервисе. Но вообще, если у тебя юзеры и комменты нужно в одной транзакции обрабатывать - ты уже не туда свернул раньше.

То есть если зафейлит один из запросов, вы сделаете отмену как? Например, выше был запрос на создание ресурса, следующий запрос зафейлил, и вы сделаете запрос на удаление создания предыдущего ресурса?

Репозиторий доступа к базе не должен включать кэш, это отдельная сущность. Надо кэшировать, делай прокси с интерфейсом репозитория который будет кешировать и при необходимости обращаться к репозиторию БД. Компоненты будут независимы и можно будет исключать при необходимости кешь или заменять репозиторий: не меняя другого кода.

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

Я храню тразакции в неком TransactionStore. В контексте передаю идентификатор транзакии. В итоге дергаются два репозитория и передаётся им контекст с одним идентификатором. В репозитории достаётся нужная транзация из TransactionStore и запрос делается через нее. Если зафейлит одн запрос, то отменятся и все остальные в других репозиториях. Я вроде вам уже кидал ссылку на реализацию этого всего))

Это вполне нормальный кейс, когда несколько сущностей в транзакции. Передавать транзакцию в сервис – а дальше как? Окей если у нас под каждым репом SQL БД с общим коннектором и мы передаем единую транзакцию. А если разные базы то как?

А вот почему мы будем считать это отдельной сущностью? Задача у БД и Кэша у одна

Неа, не кидали. Буду благодарен за ссылку