вызов "лишних" функций и странный уровень абстракции - service
Странно, но я почему-то решил, что это было ваше решение, писать именно так. Если решение вам кажется странным, то вам не кажется.
Как бы сделал я, если бы мне нужно было реализовать пример с уроками и студентами. 3 основных пакета, main, student, lesson. Так же, наверняка появился бы какой-нибудь пакет specs, в котором бы лежали структуры данных, которые API-шка принимает на вход и возвращает на выходе, у принимаемых структур так же были описаны методы для валидации.
Пакеты student и lesson это скорее всего были приватные пакеты для данного проекта, то есть они бы лежали в internal. Суть каждого пакета сводится к тому, что в нём описаны публичные функции для получения/создания данных в/из базы. Каждая функция принимает на вход указатель на коннект к базе. В эти же пакеты можно положить структуры, которые будут приниматься/возвращаться функциями пакета, так называемые DTO. Функции пакетов удобно тестировать, просто передав на вход замоканую базу.
В пакете main 2 структуры studentGroup и lessonGroup в которых был бы указатель на коннект к базе, а так же все http методы для работы с данной сущностью. Каждый метод вычитывает данные из запроса, валидирует их, вызывает нужные функции из пакетов, описанных выше и после пишет результат. Причём никто не мешает использовать функции обоих пакетов при необходимости. Так же в пакете main идёт создание подключения к базе, создание http.Handler, в котором идёт создание studentGroup, lessonGroup а так же привязка их методов к нужным http методам и url-ам. Функции структур удобно тестировать, просто передав при создании замоканую базу, или, если угодно, то можно передать настоящую базу в рамках более серьёзного тестирования.
Всё банально просто и прямолинейно, без лишних абстракций и интерфейсов, как завещал дядюшка Дэйв =)
