Я усложняю или так правильно?

Question

[imsetup]

Я решил написать каркас чистой архитектуры, который бы использовал в дальнейшем в своих pet-project. Я опирался на принятые сообществом Golang правила .
Так вот ближе к вопросу, на данный момент у меня архитектура примерно такова:
├── internal
│ ├── users/v1
│ │ ├── service
│ │ ├── repository
│ │ │ ├── postgresql
│ │ │ │ ├── postgresql.go
│ │ │ ├── redis
│ │ │ │ ├── redis.go
│ │ └── handler

(Лишнее я не стал писать, лучше сосредоточимся на проблеме)

В файлах postgresql.go и redis.go находятся интерфейсы, структуры и функция(Adapter), которая возвращает interface

code

package postgresql

type PostgreSQL interface {
	Test()
}

type postgreSQLRepository struct {
}

func NewPostgreSQL() PostgreSQL {
	return &postgreSQLRepository{}
}

func (r *postgreSQLRepository) Test() {}

Инициализация баз данных будет примерно такая:

code

userPostgresql := postgresql.NewPostgreSQL
userRedis := redis.NewRedis

и дальше таких инициализаций будет еще больше, эту проблему я решил, добавив в repository файл repository.go с таким кодом

code

package repository

func NewRedis() redis.Redis {
	return redis.NewRedis()
}

func NewPostgreSQL() postgresql.PostgreSQL {
	return postgresql.NewPostgreSQL()
}

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

code

func main() {
	repository.NewPostgreSQL()
	repository.NewRedis()
}

Теперь вопрос: Правильно ли я сделал или я слишком усложнил код? Конечно, я находил решение, просто кидать файлы postgresql,go, redis.go в repository, но мне такой исход не понравился, потому что там еще будут тесты и все перемешается.
Я надеюсь на открытый ответ и если у вас есть решение по проще, рад был бы выслушать вас.

Answer 1

[Andrey Tsvetkov]

По ссылке нет никаких принятых сообществом правил. Это просто чья-то фантазия, о чём писал Расс Кокс в issue данного репозитория.

Интерфейсы в go принято объявлять там, где они будут использоваться, а не там, где создаётся структура реализующая данный интерфейс. У вас функции возвращают интерфейс, так в go не принято, функция может принимать значения и интерфейсы, но возвращать должна значения, исключение интерфейс error.

Я бы вам рекомендовал ознакомиться с переводом советов от Дэйва Чейни, многое прояснится, там же есть ссылка на оригинал. Сам регулярно перечитываю данный материал

Answer 2

[mayton2019]

Если ты начинающий - то лучше написать работающее приложение. А архитектура должна быть мотивированной.
Вот в книжках по шаблонам проектирования так и пишут дескыть motivation.

А если на пустом hello world делать архитектуру - то оно выглядит как-то странно. И принцип KISS/Yagni
никто не отменял. И бритву Оккама.

Comments

[imsetup]

Все-таки хочется сделать "правильнее", т.к некоторые проекты будут мелькать в моих резюме.

[mayton2019]

imsetup, ну для проектов нужно содержание. Идея какая-то. А то так любой школьник зайдет
например в spring initializer и накликает мышкой там тыщи технологий. И получит шаблон проекта.
Да есть такое в Java. Понторезка такая. У вас в Go еще нету наверное. Ну оно и хорошо.
Мне нравится когда лаконично.

И знаешь как мудрые говорят. Хорошо там где нечего отнять

Answer 3

[Oleg Shevelev]

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

Например:
1. вы можете группировать всё по объектам (так появляются каталоги users/v1)
2. вы можете группировать всё по слоям (хранилища отдельно, сервисы с хендлерами отдельно, команды отдельны и так далее)

Вам стоит выбрать правила по которым происходит импорт, иначе может сложиться ситуация когда users/v1 ссылается на groups/v1 а groups/v1 ссылается на users/v1 и приводит к не возможности это скомпилировать.

Вот пример второго варианта:

tree .
.
├── Dockerfile
├── Makefile
├── README.md
├── api
├── dbconfig.yml
├── docker-compose.override.yml
├── docker-compose.yml
├── env
│   ├── postgres.ci.env
│   ├── postgres.env
│   ├── postgres.example.env
│   ├── testing.ci.env
│   ├── testing.env
│   └── testing.example.env
├── examples
│   └── config.user.add.yaml
├── go.mod
├── go.sum
├── internal
│   ├── commands
│   │   ├── cli
│   │   │   ├── command.go
│   │   │   └── users
│   │   │       └── command.go
│   │   └── server
│   │       └── command.go
│   ├── constant
│   ├── service
│   │   └── service.go
│   ├── services
│   │   └── grpc
│   │       └── users
│   │           └── service.go
│   └── storages
│       ├── storages.go
│       └── users
│           ├── interface.go
│           ├── postgres
│           │   ├── add.go
│           │   ├── storage.go
│           │   └── storage_test.go
│           ├── redis
│           │   ├── add.go
│           │   ├── storage.go
│           │   └── storage_test.go
│           ├── tests
│           │   ├── add.go
│           │   ├── delete.go
│           │   └── generage.go
│           └── user.go
├── main.go
└── migrations
    ├── 20231217192045-schema.sql.sql
    └── 20231217192051-other.sql.sql

19 directories, 35 files