(перевод картинки из предыдущего поста)
Скрытые издержки корпоративной архитектуры .NET:
Ад отладки.
Я провёл более 13 лет, работая с кодовыми базами .NET, и постоянно наблюдаю одну и ту же картину:
Команды создают абстракции уровня крепости для проблем, которых у них нет.
IUserService вызывает IUserRepository.
IUserRepository оборачивает IUserDataAccess.
IUserDataAccess вызывает IUserQueryBuilder.
IUserQueryBuilder наконец-то обращается к базе данных.
Чтобы изменить одно правило валидации, вам нужно пройти через 5 уровней.
Чтобы исправить баг, вам нужно открыть 7 файлов.
Оправдания всегда одни и те же:
«А что, если нам нужно будет заменить Entity Framework?»
«А что, если мы сменим базу данных?»
«А что, если нам понадобятся несколько реализаций?»
Что если то, что если это.
Реальность:
Эти «что если» не сбываются в 99% случаев.
Я не видел ни одного проекта, который сменил бы свой ORM.
Но я видел десятки разработчиков, которые тратили часы на навигацию по лабиринтам абстракций.
Новые разработчики не понимают, куда поместить новый фрагмент функциональности.
Старшие разработчики отлаживают код, который имеет больше уровней, чем свадебный торт.
Конечный результат?
Вы тратите больше времени на навигацию, чем на создание.
Послушайте, хорошие абстракции скрывают сложность.
Плохие абстракции создают её.
Большинство корпоративных приложений .NET имеют слишком много второго типа.
