Абстракции vs. привязка к технологии

Абстракции vs. привязка к технологии

Считайте это продолжением "От слоистой архитектуры к DDD" (https://t.me/dmkjfss/28). Я ищу компромисс.

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

Плюсы и минусы использования объектов без абстракций:

• быстро пишутся с нуля
• проще читаются
• сложнее расширяются

При использовании абстракций, соответственно, всё наоборот. Это довольно общепринятая вещь, но я в ней начал сомневаться. Думаю примерно о таком:

1️⃣ Абстракция означает только явное указание свойств объекта. Неявно они существуют в любом случае. Представим, что в неком приложении есть объект с неким свойством, которое используется в другом месте. Получается, объект должен им обладать, иначе его нельзя вызвать. Можно, конечно, прописать абстракцию, которая будет обозначать наличие этого свойства, но и без этого оно необходимо, потому что используется.

2️⃣ Такие абстракции часто подгоняются под свои имплементации, хотя и кажется, что они универсальны.

3️⃣ Для медленных языков программирования: добавляются проблемы. Например, в питоне создание ещё одного класса с абстракцией может ощутимо замедлить работу приложения.

4️⃣ Для модульного монолита/микросервисов: каждый модуль/сервис почти полностью или полностью изолирован от других модулей/сервисов, то есть нет потребности в сложной архитектуре и куче абстракций внутри каждого модуля, ведь он представляет собой крошечное приложение.

5️⃣ В реальности замена объекта на аналогичный происходит крайне редко. Сложно представить ситуацию, в которой требуется много раз заменить интерфейс для базы данных или для почты.

Напоминаю, всё это относится только к абстракциям для единственного объекта, а не вообще ко всем абстракциям.

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