ну, не всегда. иногда разделяют репозитории по логике.
тут всё, что связано с юзверями, а там всё, что с городами (условно)

Нет

Чтобы не писать бойлерплейт на обслуживание хаба соединений, а делать лишь sse.Publish(url)

Я не вижу стандартной либы по вопросу sse. Скиньте ссылку плз

Я имел в виду ту, что первая гуглится

Вообще, можно делить как заблагорассудится. Нужны аргументы почему именно так нужно разделить.  Да и, если подумать, удобный в аргументировании S никто не отменял (из SOLID'a). Можно разделять репозитории по одному на сущность и аргументировать, что иначе ты нарушаешь S. И усё.

Половина измышлений мартина - полная чушь, 30 процентов - банальщина

Есть либы которые гуглятся по server side events, есть которые по имени стандарта server sent events, всего из около 10. Мне вам сравнительный анализ конкретно выдать сейчас?
Я не вижу ни одной либы, которая покроет все мои задумки,
Такие как поддержка gzip, стопроцентная тестируемость и бенчмарки, отсутствие deprecated решений, функционал со множественными подписками, а не с единственной,
устойчивость либы к конкурентному использованию, например к старт/стопу

- Все принципы SOLID несколько лет назад были обоснованы с использованием Логики Хоара (Можете найти обоснование и попробовать его научными методами опровергнуть)
- Вся суть Clean Architecture строится вокруг идеи "Высокоуровневый код не должен зависеть он низкоуровнего" (За редким исключением при необходимости узких оптимизаций. И этот принцип можно встретить в огромной куче существующих IT систем разных мастей)
- То что очевидно одним не очевидно другим.
- Абсолютно не имеет значения как разбивать код по папкам, если соблюдено правило зависимостей и абстракции не текут.

На каждом проекте будет свой Publish. В одном коннекшоны будут привязаны к кользователю, в доугом паблиш будет оправилять всем активным, в третьем publish нужно реализовать через бизнесовые группы. Учитиывая стандарт, а именно наличие 2х заголовков, логику рассылку уведомлений по коннекшонам нужно пилить везде свою

Это означает "за всё хороше против всего плохого". Тут в конкретике вопрос, а не в общих рекомендациях

Всё это не нужно в данном случае. Аутентифицировался, подписался - получи пуш. Фсё

Все равно будет S нарушаться. Если заглянуть в Agile Software Development, Principles, Patterns, and Practices, у него в примере Payroll Database он в итоге разбивает класс PayrollDB с методами типа getEmpoyee(), getRecords() на класс по методу. то есть классы GetEmployeeOperation, GetRecordsOperation с методами Run…Operation. Что по сути сводится к банальным функциям, если выкинуть классы.

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

S постоянно нарушается. Потому что каждый формулирует, что такое ответственность и где проходят её рамки, сам.

А на каком языке пример? Может причина в том, что тогда в ходу была Java которая к тому же не имеля возможности создавать функции вне классов??

Я же не спорю.

Интересно, как определили рамки ответственности у такой абстрактной величины как некое T и какое определение этому слову дали. Нужно будет почитать.

Да, в джаве ок, там иначе нельзя. Но в Го та же проблема: функцию то сделать можно, но как нам это скрыть за интерфейсом? Может есть какой-то ФПшный подход (а он наверняка есть), чтобы “мокать” конкретные функции, но я не знаю его (

Самый лучший принцип разработки, "нормально делай, нормально будет". Лучше ещё не придумали.

Не надо анализ. Я употребил слово вкратце. Ну gzip решается элементарно, start/stop достаточно на уровне сервера. Устойчивость к конкурентному использованию и депрекейтед решения - это как?