Да. Но не совсем, при норм продумывании интерфейс должен диктовать домен, а не либа.

это интерфейс взаимодействия с внешней библиотекой

я не о внутренней структуре системы

там понятное дело DDD

Тогда не понял

Совсем примитивно на реальном примере двухнедельной давности. Мне нужна библиотека работы с google sheets. Подключаю абстрактный google-spreadsheets, типов для рескрипта у нее нет. Описываем абстрактный интерфейс взаимодействия с этой библиотекой в виде типов. Проходит время. Оказывается что библиотека не умеет фундаментальной вещи. Замена библиотеки на другую производится написанием фасада, с таким же внешним API

Я же не говорю, что на js это не возможно, я говорю, что в ts с этим гораздо удобней работать. Ты видишь все типы ошибок, которые вываливаются из юзкейсов. Ты их можешь корректно мапить на ошибки http например. Если ты что-то упустил, то тебе компилятор поругает. А что же js? Чтобы понять, какие ошибки оттуда сыпятся, мне надо ходить по всем тестам, которые проверяют ошибки? А главный посыл такой - это очень явно, типы тут сильно помогают. На js разбираться в этом всём не самое приятное.

У кого есть ссылочка на проектик с идеальной архитектурой?

Идеальных архитектур не существует 🙂

наверное у тех проектов где программист - и заказчик и исполнитель

Да, но логика и так в адаптере будет даже если просто прокид методов. В случае замены либы меняем адаптер, да. Но это норм и не афектает другие части. Под адаптером я понимаю промежуточный слой между доменом и либой

Максимально хорошая архитектура*
На такой есть ссылочка?

Он нам нужен в любом случае, чтоб избежать проблем при замене либы.

Вообще орм не совместим с ооп

Почему?

Что лучше mvc или service layer?

Мне удобней поддерживать service layer.

Я правильно понимаю, что в таком случае, роутер дергает контроллер, а тот дергает сервисы?

Mvc это паттерн для фронта

Но кучу различных апи написаны используя models and controllers