Мое имхо по итогам обсуждения поста:

Ребята это секта... секта свидетелей DI фреймворков, отпочковавшаяся от секты свидетелей TDD. Вообще имхо DI фреймворки появились из за того, что сектантам TDD было необходимо тестировать приватную логику, а по их канонам unit test этого делать нельзя. Поэтому был применен ряд шельмований, приватную логику перекрестили в сервисы вытащили их наружу. Здесь можно вспомнить COM, который решает аналогичные DI фреймворкам задачи, но в те времена не было движения TDD и поэтому COM не стал религией, а остался инфраструктурным решением.

Ни DI ни TDD ничего не гарантируют разработчику, ни от чего не защищают и ни в чем не помогают. Зато гарантированно служат серьезным источником оверхеда. Как же им удается иногда демонстрировать свою полезность? А все элементарно... например код веб систем, можно разделить на две части — бизнес логика и код взаимодействия с системными сервисами UI, DB и т.д. Взаимодействие с системными сервисами разработчику понятно, отлично проработано и имеет долгую историю. Что провоцирует наивные умы, особенно на первых этапах проекта, запихивать бизнес логику прямо в код который реализует взаимодействие с системными сервисами. Так создаются шедевры спагетти кода. Что делает TDD? Оно постулирует — сначала пишем тесты. Все верно, в юнит тестах нет взаимодействия с системными сервисами поэтому структуру бизнес логики приходится прорабатывать отдельно от всего т.е. приходится строить архитектуру. Вот и весь трюк. Цена такого подхода — значительный оверхед кода (уровень которого зависит от религиозного фанатизма разработчика), потому как бизнес логика гарантированно будет уточнятся и изменяться и тесты придется переписывать, но как мы теперь понимаем, для проработки бизнес логики и построения архитекуры тесты на самом деле лишь полезны, но никак не обязательны.

Мое имхо по итогам обсуждения поста:

Ребята это секта... секта свидетелей DI фреймворков, отпочковавшаяся от секты свидетелей TDD. Вообще имхо DI фреймворки появились из за того, что сектантам TDD было необходимо тестировать приватную логику, а по их канонам unit test этого делать нельзя. Поэтому был применен ряд шельмований, приватную логику перекрестили в сервисы вытащили их наружу. Здесь можно вспомнить COM, который решает аналогичные DI фреймворкам задачи, но в те времена не было движения TDD и поэтому COM не стал религией, а остался инфраструктурным решением.

Ни DI ни TDD ничего не гарантируют разработчику, ни от чего не защищают и ни в чем не помогают. Зато гарантированно служат серьезным источником оверхеда. Как же им удается иногда демонстрировать свою полезность? А все элементарно... например код веб систем, можно разделить на две части — бизнес логику и код взаимодействия с системными сервисами UI, DB и т.д. Взаимодействие с системными сервисами разработчику понятно, отлично проработано и имеет долгую историю. Что провоцирует наивные умы, особенно на первых этапах проекта, запихиать бизнес логику прямо в код взаимодействия с системными сервисами. Так создаются шедевры спагетти кода. Что делает TDD? Оно ограничивает — сначала пишем тесты. И тут все верно, в юнит тестах нет взаимодействия с системными сервисами поэтому структуру бизнес логики приходится прорабатывать отдельно от всего т.е. приходится строить архитектуру. Вот и весь трюк. Цена такого подхода — серьезный оверхед (уровень которого зависит от религиозного фанатизма разработчика), потому что бизнес логика гарантированно будет уточнятся и изменяться и тесты придется переписывать, но как мы теперь понимаем, для проработки бизнес логики и построения архитекуры тесты на самом деле лишь полезны, но никак не обязательны.