Size: a a a

2021 June 12

E

Esusss in Go-go!
Привет!
Просмотрел пару статей на тему "Clean architecture, DDD" и т.д.
Там в основном делают разделение на handler’ы, repository, service и в каждой из папок пишется логика для всех сущностей (работа с (например) юзером размазана по этим папкам), а потом последовательно прокидывают зависимости (db -> repo -> service -> handler) и собирают все в одном файле (app.go, условно)

Я хочу вынести так называемые фичи в отдельные папки - например user и чтобы там уже была вся работа с ним (и хэндлеры, и репозитории, и сервисы)

Собственно, вопрос:
Могу ли я вынести всю логику работы с юзером в отдельную папку и также просто подключать в общий репозиторий, сервис и хэндлеры? Или это уже немного не совсем верный путь и надо сделать как-то по-другому? (Для меня важно достичь разделения фичей по своим директориям, а не раскидыванием работы с ними по всем папкам)

Заранее благодарю за ответы и прошу прощения за столь длинное сообщение!
источник

OE

Oleg Elizarov in Go-go!
Так вроде чистая архитектура и направлена на то , что ты делишь проект на бизнес сущности. И в каждой папке бизнес сущности и будут слои чистой архитектуры
(User содержит Delivery, Usecase, repository)
источник

D

Dmitriy in Go-go!
Layered архитектура обычно плохо пахнет, ddd как раз про другое
источник

Z

Zver in Go-go!
Это прям перпендикулярно чистой архитектуре.
источник

E

Esusss in Go-go!
Вы про первую часть сообщения?
источник

Z

Zver in Go-go!
По вторую.

Вынесение работы с одной сущностью на всех уровнях в отдельны пакет. СА это как раз наоборот.
источник

RL

Ragnar Lodbrok in Go-go!
Я правильно понимаю, что вы предлагаете цепочку db -> repo -> service -> handler поместить в отдельную папку users?
источник

Z

Zver in Go-go!
По мимо этого что вы смешивайте в одну кучу, так ещё и на разных уровнях условный user может быть разным.
источник

E

Esusss in Go-go!
Принял
А в каком плане - разный?
источник

E

Esusss in Go-go!
Почти
Подключение к бд - само по себе и потом его прокидывать по все репозитории
А так - да, логику работы с юзером вынести в отдельную директорию (но как понял, это не совсем хорошо, о чем я в итоге думал сделать)
источник

D

Dmitriy in Go-go!
В зависимости от бизнес контекста у него будет разный набор полей
источник

НО

Николай Оськин... in Go-go!
Подскажите, есть ли какой-то стат. анализатор/linter, который поможет отловить потенциальный nil pointer dereference

Пример кода:
package main

import "fmt"

type A struct {
 Name *string
}

type B struct {
 A *A
}

func main() {
 deref(&B{})
}

func deref(b *B) {
 fmt.Println(*b.A.Name) // panic: invalid memory address or nil pointer dereference
}
источник

E

Esusss in Go-go!
Хм, принял, благодарю
Могу вас еще попросить скинуть +- нормального чтива о ddd (внутри экосистемы го и вне)?
источник

RL

Ragnar Lodbrok in Go-go!
Вы можете столкнуться с проблемой, когда сервису надо работать с двумя сущностями одновременно
источник

E

Esusss in Go-go!
Да, вот только об этом подумал, что прокидывание чужого репозитория будет совсем плохой кашей..
Благодарю!
источник

L

LoganFrench in Go-go!
всем привет! как мне хранить только 10 элементов в массиве. нужно хранить только 10 последних значений.
a = a[1:9]
a[0] = value;
такое сгодится?
источник

L

LoganFrench in Go-go!
ничего там с утечками не будет?
источник

VY

Vladislav Yarmak in Go-go!
10 последних по итогу чего?
источник

AD

Alex Dok in Go-go!
Что лучше взять вместо gorilla router? А то там походу чето сломалось (сломалось взятие переменных передаваемых через get/post:  не работает  v := mux.Vars[“key”]
источник

VY

Vladislav Yarmak in Go-go!
лучше взять и починить, осуществить вклад в опенсорс
источник