у меня след структура
pkg/repository/account.go (Тут находится объявление и реализация AccountRepository)
services/account/service.go (Тут находится объявление структуры сервиса (который принимает репозиторий) и его реализация)

Т.е. описать интерфейс в repository будет ошибочно и стоит это сделать в account/?

и в случае если он лежит рядом с сервисом, он может быть неэкспортируемым? (с маленькой буквы)

Ну не то, чтобы прям ошибочно. Но в го интерфейсы стандартно объявляются рядом с потребителем. Твой репозиторий может удовлетворять нескольким интерфейсам. Например в одном сервисе у тебя от репозитория нужно только Get и Delete, а другому сервису - Get, Create и Filter. Создаёшь два интерфейса у каждого сервиса с нужными методами, в оба сервиса передаёшь одну реализацию интерфейса со всеми методами. В итоге и реализация одна и у сервисов есть доступ только к нужным методам.

Не экспортируемым если делать, могут возникнут трудности потом с тестированием, например (если тесты в отдельном пакете будут) или со всякbми DI типа wire

большое спасибо, дельный совет)

Привет, вопрос знатокам. Встречали ли где-нибудь упоминания, что параметры интерфейсов  должны быть простыми типам из stdlib? Интересно, что stdlib сама приемущественно только их и использует.
Причина вопроса - а если тип собственный, составной, то при объявлении интерфейса, куда он должен ссылаться. Приведу пример, k8s в своих пакетах ссылается сразу в несколько пакетов:

GetResource() schema.GroupVersionResource
GetOperation() Operation
GetUserInfo() user.Info

https://github.com/kubernetes/kubernetes/blob/ce8cccb96659e10a224c0dfe089508e1505732c9/staging/src/k8s.io/apiserver/pkg/admission/interfaces.go#L31

привет! никто не мокал официальный mongo-go-driver?

GetResource() schema.GroupVersionResource
GetOperation() Operation
GetUserInfo() user.Info

Понятно, что тот, кто захочет объявить тип, удовлетворяющий данному интерфейсу, должен импортировать все пакеты. И самый основной вопрос - а вообще законно ли здесь определение

GetOperation() Operation

? Объявляется интерфейс, что может принимать тип, объявленный здесь же, это вообще как?

это норм

GetOperation() Operation

это возврат типа же, а не прием, пакет может возвращать свой тип, почему нет

А, ну кстати да, возврат окей. Там есть и прием, если поискать аккуратней)

а это внешний интерфейс пакета ? или внутренний ?

но и с приемом нет никаких проблем

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

но так не делает stdlib, а если бы делал, проблемы бы конечно были, наверное. Ломает расширяемость и по сути прибивает интерфейс к конкретной реализации

да, я вижу k8s так и делает, но вместе с этим, может встречали формальное утверждение как делать нужно и как не стоит?

Всем привет:
1. Подскажите, если проходить по слайсу структур циклом и на каждой итерации менять значение, изменятся ли значения в самом слайсе? (слайс форма [ ] type)
2. Или нужно добавить закоментированные строки?

    for i, server := range servers {
      control.PowerStatus(&server)

      if server.Power != "Running" {
        server.Network = "Off"
        //servers[i] = server
        continue
      }

      control.NetworkStatus(&server)
      //servers[i] = server
    }

в рефакторинге есть даже методика "замена множества переменных одной структурой"
вот и делайте выводы проводя аналогии

опять же, не существует формальных утверждений, есть рекомендации которые можно соблюдать или не соблюдать
даже если их не соблюдают, ну, живите с этим если вам нужен этот пакет :)

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