лёгкость или сложность сервиса по-моему значения не имеет. У меня и для лёгких и для сложных сервисов используются репозитории двух реализации - кеш и дб. Из бизнес логики работаю с кешом. При этом кэш - адаптер над бд. При получении данных кеш смотрит данные у себя - если есть выдает. Если нет - лезет в бд и кеширует в себя. Если идёт изменение данных кеш сразу дергает бд, затем инвалидирует данные у себя.
При этом для части данных кеш ин мемори, для части распределенный - редис, эластик.
А вы говорите "используйте" sql.db 😂

о, жму руку. у меня так же

если у нас Order и User связаны в некой транзакции - они часть одной сущности / одного интерфейса

если у нас Order и User связаны в некой транзакции - они часть одной сущности / одного интерфейса

Так почему не сделать один общий интерфейс? Зачем разделять по сущностям? сущности будут постоянно пересекаться в операциях

я предпочитаю делить как минимум на идемпотентные интерфейсы и интерфейсы записи

А в чем профит?

Можно пример?

А никто не знает список CLI, которые парсят golang source code и выдают информацию о нем. Например, мне нужно найти список всех интерфейсов в package или файле

goland

вот и хорошо, и не надо cli

а зачем нужен отдельный скриптик, если есть go generate?

Я же написал use case, хочу сделать скриптик, который будет находить все интерфейсы в package\файле и генерировать моки. При чем здесь идейка?