Комментарии 13
Лучше это всё прямо в яве и оставлять.
Зачем оно гошникам?

Не говоря уж про gorm.
А где бы найти как правильно такое делать? Ведь для ослабевших старых умов, типа моего, вышеописанное может стать руководством к действию.
effective go, go blog, полно ж первоисточников.

Ну вот даже например посмотреть как использовать интерфейсы.
если на заборе написать clean, он чистым не станет.

Делать как в статье не нужно.
Разве `json:"id" gorm:"primary_key"` уже не нарушает принципы чистой архитектуры? В бизнес сущность тащим логику отображения и хранения
+100
Пихать в бизнес-правила завязку на низкоуровневую сущность — это точно не то, о чём писал Роберт Матрин.

Крутая архитектура, особенно когда у нас есть два разных файла sqlHandler.go в папке infrastructure, и sql_handler.go в папке database. И два файла user_repository.go в разных папках.


А это вообще выглядит как мем:
domain — Entities
usecase — Use Cases
interface — Controllers Presenters
infrasctructure — External Interfaces


Больше абстракций и терминов богу терминов?


Руки бы оторвать за такой CLEAN подход.

Один хороший человек(кажется его звали Дэйв) как-то сказал, что любой пакет, если его имя не cmd или internal, должен содержать код, в вашем пакете interfaces я не вижу кода. Так же, этот хороший человек писал, что имя пакета должно отображать назначение, а не содержимое. За отсутствие возможности конфигурировать порт для апишки и данные для соединения с базой хочется выдать отдельный жирный минус. Ну и конечно же, GORM — величайшее зло.
Кстати, вышел GORM 2, по производительности приближен к database/sql. Рефлексия, да есть.
По поводу, что GORM — зло: подскажите, правильно ли я понимаю, что в Go Entity (как отображение таблиц БД на структуры) не нужны, и нужно делать функции, которые возвращают некие DTO (структуры, не связанные непосредственно с таблицами, а связанные только с данными, которые нужны — то есть это могут быть данные из нескольких таблиц)? А в самих функциях либо чистый SQL, либо квери-билдер типа Squirell.
Это не clean architecture, а dirty s.

Бизнес модели не должны знать про gorm, а тут какие-то аннотации. Почему мы вообще полагаемся на технический слой?

Контроллеры кривые, в го же есть нормальный duck typing:

type Repository {
  GetByID(userID int64) (models.User, error)
}

type Controller {
  repo Repository
}

func NewController(repo Repository) *Controller {
  return &Controller { repo: repo }
}

func (c *Controller) GetUser(userID int64) (response, error) {
  user, err := c.repo.GetByID(userID)
  if err != nil {
    // ..
  }

  // some logic here
  return response, nil
}


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

framework специфичные штуки, от echo как раз можно в архитектурном слое использовать, но не в контроллерах и бизнес домене.

Такой код с interface{}
Create(obj interface{})


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

ну т.п., тут куча всякого mess'а, не рекомендую кому-то так делать
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.