Задать вопрос
@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, но мне такой исход не понравился, потому что там еще будут тесты и все перемешается.
Я надеюсь на открытый ответ и если у вас есть решение по проще, рад был бы выслушать вас.
  • Вопрос задан
  • 292 просмотра
Подписаться 1 Средний Комментировать
Пригласить эксперта
Ответы на вопрос 3
yellow79
@yellow79
Senior Software Engineer
По ссылке нет никаких принятых сообществом правил. Это просто чья-то фантазия, о чём писал Расс Кокс в issue данного репозитория.

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

Я бы вам рекомендовал ознакомиться с переводом советов от Дэйва Чейни, многое прояснится, там же есть ссылка на оригинал. Сам регулярно перечитываю данный материал
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Если ты начинающий - то лучше написать работающее приложение. А архитектура должна быть мотивированной.
Вот в книжках по шаблонам проектирования так и пишут дескыть motivation.

А если на пустом hello world делать архитектуру - то оно выглядит как-то странно. И принцип KISS/Yagni
никто не отменял. И бритву Оккама.
Ответ написан
@mantyr
Пишу много Golang кода с удовольствием:)
Вы можете использовать любые правила которые считаете удобными.

Например:
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
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы