Как правильно описывать архитектуру для REST API приложения?

Question

[Егор Полянский]

Я начал писать свое полноценное REST-API приложение на Go, но проблема описания архитектуры приложения мне остается не совсем понятной. Я понял суть разделения на трехслойную архитектуру, но последующие внутренние архитектурные нюансы в каждом источнике отличаются настолько, что не могу уловить какой-то общий паттерн (как, например, описываются логгирование, конфиги, роутинг).
Так, например, в рамках одного из видео по написанию REST-API была предложена такая схема (она не полная, но суть, я думаю, понятна):


Подскажите, пожалуйста, источники, где к этому можно обратиться.

Comments

[hellocashmere]

Я обычно config выношу на уровень с cmd. Логгеры, БД, которые я переиспользую из проекта в проект в pkg. internal у меня разбит на сущности, допустим users, а внутри transport, service, repository.

Answer 1

[Пума Тайланд]

qiangxue/go-rest-api на гитхабе — там cmd/internal/pkg с разбивкой по фичам, сразу видно где logger, где config, где роутер. Ещё go.dev/doc/modules/layout — официальная дока. golang-standards/project-layout тоже смотрят, но это не стандарт, а community-сборник. Вариаций много, единого правильного нет.

Answer 2

[VoidVolker]

Минимум:

• Схема/диаграмма взаимодействия с API, а так же внутренней логики
  
• Документация по всем методам/точкам входа
  
• По параметрам методов
  
• Возвращаемому результату
  
• Ограничения самого API, методов и параметров
  
• Подробное описание ошибок и кодов ошибок
  

Остальное — в зависимости от особенностей конкретного API и фантазии разработчика.

Пример описания схемы работы API