V L

Как быть, если в рамках одного usecase необходимо сделать например CreateUser и LogAction, бд одна, репозитории разные и хочется использовать общую транзакцию?

В вашем случае (указатель) - будет уже шесть 🙂 И это мы говорим про чтение. А если начнем про модификацию? (Хватит про оптимизации пожалуйста)

А когда вы в вебе запрашиваете страницу с несуществующим url (считай id) и получаете 404 - это ошибка?

nil, err ? Хотя я не уверен, что тут требуется возвращать указатель.

возможно вам поменять хранилище данных под то, что лучше работает с тем поведением данных и операциям над данными типом данных, что вы используете?

Зачем рефлексия, когда есть wire?

У меня большое подозрение, что работать не будет. Для shared memory свои сисколлы же, как их воткнуть в реализацию стандартных горутин?

У вас проблема, что нужно в разных методы разных классов использовать один и тот же объект, содержащий транзакцию к БД. Как это можно решить?

Вы все ближе к ФП, разве это плохо? 🙂

партиционирование не помогает?

Кто подскажет как сейчас обстоят дела с кросскомпиляцией + cgo? Сильно сложно под вин из линуха собрать или лучше забить на кросс?

А если у вас раньше синхронные запросы не обрабатывались идемпотентно, то может и тут не надо?

Кажется это буква I в SOLID. Зачем вам интерфейс с теми методами, что вы не используете в данном usecase?

Вот возможно стоит подумать над другими вариантами, если универсальность уже создает проблемы?

Я же правильно понимаю, что у вас транзакция не должна захватывать несколько юзкейсов одновременно?

Но ведь даже если указатели и не синхронизирован доступ к мапе, то race будет ругаться?

где вариант "в go нет конструкторов"?

Может можно тут попробовать также, а когда сделаете - возможно увидете как можно упростить?

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

А если бы там возвращалось time.Time, а не структура, вы бы тоже указатель сделали?