+1

В Go функции можно передавать как аргументы. И использовать в качестве типа подставляя потом туда любую функцию которая удовлетворяет определению

Короче либа должна быть полностью thread safe.
Если я по ошибке стартую рутину процессинга ивентов из двух потоков, я должен получить консистентное состояние данных

Так то да. Но вот для примера: у меня есть Gateway для пользовательских сообщений, например. В нем есть банальные CRUD методы в базу и метод на подписку новых публикаций, для лайв апдейта ленты, и реализован он через очередь. И, например, метод Update() и метод Subscribe() меняются по разным причинам – из-за реализации внутри. А так нам приходится в одном классе Gateway шарить инстанс на базу и на очередь, хотя Subscribe база не нужна, а остальным операциям не нужна очередь

Это просто общая фраза которая ни на какой принцип не тянет. Она настолько общая, что лишена вообще какого либо смысла.

Как и S.

Нет. Нарушение S все таки можно увидеть. К примеру когда функция выглядит как: func DoBarAndBuz() или func DoFooOrBar.
А "нормально" оно у каждого свое.

У нас бы это разделилось на репозиторий и отдельно на сервис уведомлений о новых сообщениях и всё такое. В одном бы всё не было.

"Высокоуровневый код не должен зависеть он низкоуровнего" - вот это и есть банальщина, о которой я говорил. И решается оно интерфейсами го, а не абстрактными общими рекомендациями за всё хорошее.

"То что очевидно одним не очевидно другим" - вот не надо всех считать тупыми, кто не разделяет ваших взглядов. Почитайте статью, на которую я ссылку давал

Я думал вызывать методы прямо из импортируемого пакета. Например, была у нас структура PaymentGateway с методом Process. А сделал бы отдельно функцию Process, которая принимает PaymentGateway, и все это в пакете payments. И там, где нужно делать пейменты, я бы импортировал пакет payments, и дергал оттуда функцию Process, в которую передавался бы PaymentGateway, прокинутый уровнями выше.

Не знаю, нормально ли так, или это нечто неподобное

Контекстно они связаны сообщениями, мне кажется, что один класс тут бы смотрелся логичнее.

Меня и так совсем напрягает, что когда у тебя десятки сущностей, и на каждую свой сервис, репозиторий, и тд, в main происходит чудовищная по виду простыня инжектов

Никогда таких функций не видел, но видел что-то вроде имплементаций,для примера возьмём, File, который работает с файлом. Пишет, читает, перемещает. Это нарушение S? Или писать в файл должен кто-то один, а читать кто-то другой? По практике да, разделяют. Но ведь если всё собрать в одну реализацию, то тоже вроде как S не нарушен. Зона ответственности - работа с файлом. Как определить тут? Функции в вакууме удобны для рассмотрения, но на практике жаркие споры где S нарушен постоянны.

У одного моего знакомого, в проекте нет интерфейсов больше 1 метода. Потому что там S маниакально преследуют.

Если это банальщина, объясните тогда наличие оргромного кол-ва кода где практически полностью отсутствуют какие либо интерфейсы и он запутан так, что любое изменение может привести к падению приложения в абсолютно несвязанном с правкой месте?

Я не считаю ни кого тупым, я имел ввиду то, что у всех разработчиков совершенной разный опыт. И это нормально знать одни вещи и не знать других.

в небольших кодовых базах интерфейсы крайне редко нужны

Как минимум простой независимости от фреймворков встретить можно не везде. Django/RoR как стиль жизни

В любых кодовых базах где требования не ясны или бизнес не совсем хорошо понимает домен нужны интерфейсы. Иначе вы в конце концов придете к 2 финалам:
1) Выбросить и переписать все с нуля
2) Мы такого не закладывали, это невозможно

Можно и один сделать, если так удобно. Код должен быть понятен, покрываться тестами и всё такое. Остальное я уже давно не преследую. Субъективно всё это.

Объяснение - х-х-ивпродакшон-дривен-девелопмент. Чистая архитектура тут ни особо что решает.