Zero Values и никакого undefined: Чему Go научит JS-разработчика (Часть 2)

Это актуальная проблема. Как вы смотрите на создание ValueObject?

type UserAge struct {
  age int
  filled bool
}

Не удобно писать код с телефона, но, надеюсь, мысль передал. Поля приватные, экземпляр создается через конструктор. Там же может быть валидация. Публичный геттер может возвращать два значения для проверки и обработки. Zerovalue структуры будет иметь filled false, что так же корректно обрабатывается

Чистим main.go: предсказуемый старт и надежный Graceful Shutdown

Рефлексия отталкивает, конечно… неужели нельзя было сделать без неё?..

Функциональное IT искусство

подглядывают)

Хватит спрашивать у синьоров джуниорские вопросы на собеседованиях

На одном из недавних собеседований у меня спросили все методы HTTP и типы данных в Go. С одной стороны очевидно, с другой... Как-то меня недооценивают. Я даже растерялся и, кажется, вспомнил нет сё

Архитектурный паттерн для централизованной обработки ошибок в хендлерах на Go

В целом неплохо. Но для обработки ошибок в http есть 7807, можно реализовать его структуру.

А ещё, было бы прикольно сделать ошибки доменные с доменными кодами и сообщениями и в мидлвари коды домена мапить на коды http или другого интерфейса (grpc, etc)

Еще один вариант структуры go-приложения

Спасибо за статью. Многие решения откликаются во мне.

Предлагаю обсудить интерфейсы.
Почему интерфейсы репозиториев в домене?
Их необходимость ещё стоит обосновать (https://enterprisecraftsmanship.com/posts/ocp-vs-yagni/)
Но если они все-таки нужны... Мне кажется, что подход, при котором интерфейсы находятся в слое домена, взят из Джавы и прочих ООП языков, в которых в реализации явно указывается, что она реализовывает интерфейс.
В го типизация утиная и такой необходимости нет. Так зачем размазывать знание о хранении модели в слое модели?

Я предпочитаю определять интерфейсы по месту использования. В данном случае это слой приложения.