общественное мнение про надоевшую раскладку пакета. Вот на примере Employer.
В корне пакета есть employer.go. В нём структура Employer ну и интерфейсы EmployerStorage, EmployerService.
Вот теперь надо реализовать интерфейсы. Что лучше:
1. Общий пакет employer и потом employer.NewPostgreSQLStorage() и employer.NewGRPCService(), employer.NewService.
2. Много пакетов по зависимостям. Типа: postgresql.NewEmployerStorage(), endpoints.NewEmployer(), grps.NewEmployerServer()?
отдельная папочка на каждый кусок приложения логика отдельно, база отдельно, сервер отдельно интерфейсы (файл с ними) создается там, где они ИСПОЛЬЗУЮТСЯ и если юзаете их, помните, что ваши функции не должны возвращать интерфейсы, а только принимать
Нырок, потом хук снизу. 😁
Тут то бишь второе. Спасибо.
Я бы поспорил. Слой не определяется папочкой. Иногда нужно создавать два интерфейса, в двух местах.
ну так бы и написали)) Мне было лень писать "читайте чистую архитектуру, например" - т.к явно не этого ждал ТС, поэтому написал образною. Я бы не хотел, чтобы в корне проекта, рядом с конфигами, видеть *.go файлы
Я вчера какое-то видео смотрел, там вообще ахритектура строилась по типу "создаем папку с сущностью, а внутри неё сразу кладем файлы "сервсис репо хендлер", типа открыл модуль User и там сразу все его части, показлось интересным. Но я пока пользуюсь линейной типа infrastructure - adapter - domain - infrastructure
https://refactoring.guru/ru/design-patterns/go ну и плюсом, их можно смешать все. 😂
Так, если рядом с конфигами нет файлов го, то потом импорт из других мест получается типа: import "mydomain.com/projects/imortant/start/libraries/mylib/pkg/enteties/employers"
Да, начиная с корневого модуля импорт будет
Обсуждают сегодня