люди на полкилометра в море и все еще по колено

Дорогой чатик, чем вы обрабатываете markdown-тексты?
Цель: markdown-текст из редакционной админки красиво отобразить на react-фронте (NextJS).
Например, типограф применить, сделать автозамены и т.п.

Звучит как Ладога

Geoguessing, однако

Кстати, есть прикольная игра GeoGuessr (geoguessr.com). Тебя, в зависимости от выбранной категории, размещает на гугл панораме, а ты должен угадать, где находишься. Иногда можно по ней передвигаться и читать знаки, иногда по флагам нужно понять

с вами был капитан очевидность!

где?

Коллеги, как насчёт пофлеймить в пятницу ночью?

Есть у меня, скажем, интерфейс UserRepository, который, разумеется, предоставляет метод FindByID (и много других полезных методов, разумеется). Далее у меня есть доменный сервис UserService, который, натурально, требует для работы UserInterface. У сервиса тоже полезных методов в достатке.

И есть у меня транспортный CRUD-контроллер например ContentController, который в некоторые свои методы принимает UserID, по которому контент фильтруется, или от имени которого контент добавляется. Или репостится.

И так получается, что ContentController требует для работы и UserService, от которого использует кучу функционала, и ровно один метод FindByID интерфейса UserRepository.

Внимание, вопрос знатокам:

Насколько по фэншую будет добавить в UserService прокси-метод GetByID, чтобы убрать лишнюю зависимость в контроллере?

Или, говоря шире, насколько корректно в доменных сервисах проксировать тривиальные методы инфраструктурных сущностей или других доменных сервисов, от которых они и так зависят?

Golang говорит нам, что A little copy is better than a little dependency, но это относится к модулям как языковым абстракциям. С другой стороны, тут даже не copy, а вовсе прокси.

Вот зачем так на ночь глядя-то. Я предпочитаю делать в контроллере так userService.userRepository.findById(..)

Насколько по фэншую будет добавить в UserService прокси-метод GetByID, чтобы убрать лишнюю зависимость в контроллере?

В будущем этот прокси метод вполне может обрасти логикой, поэтому этот метод будет иметь статус "прокси" временно. Очевидно что лучше убрать зависимость в контроллере

забыл шляпу добавить

Это, по большому счёту, не отменяет зависимости контроллера от инфраструктуры, просто убирает один параметр в конструкторе. С другой стороны, это сразу делает доменный сервис вдвое более волосатым, потому что из него теперь торчат все методы репозитория.

но оставляет тебе возможность сделать прокси когда НАДО

одним методом больше, одним меньше

coupling не повышается

cohesion не меняется

имхо преждевременный декаплинг такая же проблема как преждевременная оптимизация

а минус зависимость из контроля понижает coupling

хорошо, что спереди написано "имхо"

Очень вряд ли этот вызов станет сложнее, он реально используется для валидации параметра, что такой юзер вообще существует, а потом использует полученного User entity дальше в работе.