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