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

У вас сейчас маленький проект с несколькими сценариями, как только вы его начнёте расширять и покрывать тестами, то думаю поймёте о чем я.

А, я понял. возможно речь о методе Performer, где конкретно привязка к реализации

Сейчас это набор методов, которые доступны контроллеру. Помимо Performer, который явно лишний, не совсем понимаю, что ему еще не нужно.

То есть мы можем разбить Storage на отдельные структуры, типа NotesStorage, со своими интерфейсами. Потом каждый этот новый сторедж добавить в контроллер. И дергать в юзкейсах только те стореджи, что нужны. Верно?

@floyernick
>export DATABASE_URL='postgres://postgres:postgres@localhost:5432/awesome?sslmode=disable'

не URL а DSN

Тут у меня общий контроллер на все юзкейсы. Насколько я помню, у Мартина под каждый юзкейс

Будет лучше, если интерфейсы зависимостей (хранилища) будет определять класс (контроллер).

Да, я сейчас допер о чем вы

Контроллер вы имеете ввиду – контроллер одного конкретного юзкейса

Правильно?

Вот у вас notesStorage более менее пример нормального интерфейса. Он оперирует бизнес моделями и отвязан от какой либо реализации. Т.е. по нему невозможо сказать что за база под этим интерфейсом лежит. SQL там или HTTP сервис... Что хотите то и подставляйте. Сегодня мнонлит и пишем в одну базу, завтра решили кусок унести в отдельный сервис, сели, написали новую реализацию для notesStorage, теперь она работает по HTTP. Остальной код при этом не изменится

То есть допустим контроллер NotesCreateController. В нем определен интерфейс Storage, который требует только один метод – CreateNote.

ты кстати не видишь тут потенциальной проблемы?

Ошибки не чекаю

Имя Storage не говорит о том, что это такое, можно придумать имя лучше.

а почему не чекаешь?

А почему имя структуры совпадает с именем пакета?

+