По факту получая те же яйца, только в профиль

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

Ну в моей жизни таких проектов было несколько :)

Собственно, решил попробовать фшарп с целью узнать как с этим борятся в других парадигмах

Да тут руки виноваты, а не инструмент же(в данном случае C#).

Но как уж многократно было сказано выше-DI и контейнеры, если писать идиоматично на фаршике-вообще не нужны.

Я не про Шарп, а про подход контроллер -> сервис -> репозиторий, причем у всех куча зависимостей через конструктор

ИМХО в фаршике если пилить идиоматично-функциональная композиция+DTO под конкретную ситуацию с использованием данных только для конкретного использования без протаскивания ненужных данных, в совокупности с выводом типов, позволяют избегать таких вот кусмачей кода c множеством аннотаций типа, куда тащится все. Одно НО-я пока сравнимых по объему с запиленными на шарпе проекты на фаршике не пилил, поэтому конкретно по фаршику-это мои теоретизирования.

В шарпе тоже все это можно избегать, и есть уже проверенные масштабируемые архитектурные решения ака CQRS+Event Sourcing, но там все равно свои ловушки есть.

Комбинаторный взрыв типов сообщений-один из самых безобидных.

Я тоже не понимаю использование DI для "управления сложностью".

Но бывают функции, где не получается отделить сайд-эффекты от доменной логики. Тогда вопрос использования DI сводится к тому, какой вид тестирования лучше применить к данному участку кода в текущих условиях: юнит-тесты или интеграционные тесты.

И кстати, в фаршике же этот архитектурный подход ИМХО должен работать еще лучше, бойлеркода сильно меньше

В фаршике DI не нужен, возможно я не прав, но буквально вот недавно (вчера-сегодня) я стал в это верить  :)

Под DI я имею в виду любой механизм доставки зависимостей, необходимых для выполнения сайд-эффекта.

Есть  конечно шальные мысли-обернуть домен, запиленный на фаршике шарповым кодом, а дальше по накатанной-DI через контейнер со своими конфигурациями под задачи(тестирование, продакшен, нагрузочное тестирование, тестовая эксплуатация), аспекты опять таки через контейнер. Но пока нет такого проекта на фаршике, где такие ухищрения бы нужны были.

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

ИМХО конечно, но вместо использования интерфейса в фаршике гораздо идиоматичнее  композиция функции.

Не, абстрагируемся от реализации DI.

ИМХО от проекта и ресурсов зависит, а также КПД конкретных действий. Скажу возможно крамольную мысль, но если требуются моки-значит проеб в архитектуре/коде налицо :) Я пришел достаточно давно к идее, что лишний код(а моки, даже пусть и через использование условно удобных фреймворков)-это ненужный код, поэтому весь не тестовый код-должен быть используемым и в проде. И тут сложность возникает написать код так-чтобы его можно было использовать вместо моков в тестах, и при этом тесты не были бы хрупкими, и не усложнялся бы раскоп проблем, если сломался смежный код, а не основной тестируемый. При таком подходе спасает группировка тестов по уровням-уровень общих компонентов(которые используются дальше), более высокий уровень, интеграционные тесты

Местами конечно без моков не удается обойтись, но к этому отношение как к неизбежному злу(ну нет идеальных решений).