Организация кода в Go

[methlab]

Автор открыл для себя «The Clean Architecture». https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

[ZurgInq]

У вас будут имена вроде controller.UserController, в которых вы дублируете имя пакета в имени типа.

Можно ведь controller.Users?

Опять же, ужасные имена вроде users.User и та же проблема с круговыми зависимостями, когда наш accounts.Controller должен взаимодействовать с users.Controller и наоборот.

С чего вдруг один контроллер должен вдруг взаимодействовать с другим? Такого вообще не должно быть.

[chuck]

С чего вдруг один контроллер должен вдруг взаимодействовать с другим? Такого вообще не должно быть.

Проблема в конфликте имен, а не взаимодействии однотипных сущностей. Controller тут как пример.

[Shtucer]

us := &postgres.UserService{DB: db}

Ой, какая красота! Сиди и думай, что это за UserService такой у постгреса. В документации нет, а он вот он. Ой! postgres для инициализации UserService требует какую-то DB.
interface в Go придуманы для слабаков. Ой! А UserService ещё в myapp есть. Странная декомпозиция…

Выгода от дублирования имени будет в том, что вы изолируете весь HTTP код внутри вашего http пакета:

Выгода?

package http
import (
«net/http»
«github.com/benbjohnson/myapp»
)

Дайте угадаю: в myapp будет import «github.com/benbjohnson/http»

[divan0]

Дайте угадаю: в myapp будет import «github.com/benbjohnson/http»

Нет, myapp это корневой пакет — там только типы и интерфейсы, у которых нет зависимостей.

[dmbreaker]

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

[divan0]

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

Про какое время компиляции речь? Секунды, минуты, часы? И какое это имеет отношение к тому, что автор комментатория неверно понял предложенную в статье модель?

Используйте интерфейсы для зависимостей как можно чаще и проблем будет меньше.

Автор статьи использует интерфейсы. Совет «как можно чаще» тоже не совсем верен. Интерфейсы абьюзить тоже не нужно без повода.

[dmbreaker]

Секунды и минуты, конечно.
Все внешние зависимости через интерфейсы. Никто не призывает абьюзить. Просто создавать свой пакет для мнимой «изоляции» — это не путь Go. Путь Go — это объявить интерфейс для внешней зависимости и работать с ним, а не с конкретной реализацией. Тогда и тесты легко писать и заменять зависимости легко.