Вообще, когда есть необходимость в применении разнотипных технологий, квалифицированные специалисты говорят о микросервисной архитектуре. =) Это мой ответ на добрую половину поста. В том числе про анализ до которого нужно дорасти.

Да, легче, тем самым добились усиления границ того же самого контекста. Какой там язык, господи, 2.5 повседневных конструкции. Язык сам по себе не является контекстом, а только то, что он выражает. Это же касается и DQL или любых других абстракций над одним и тем же контекстом. Чего никак нельзя сказать о парадигме, ООП нифига ниразу не абстракция над процедуркой, они в этом смысле не взаимозаменяемы.

Ну вот приехали, оказывается DRY мешает в SQL запросах, надо ж как.

Я так чувствую здесь опять спор ради победы? Любыми средствами, да? )

Вот те на, здравствуйте. MSA не имеет целью объединить разные методологии, у нее совершенно иные задачи. Распределение нагрузок оставим в покое, это не предмет текущей дискуссии. Основная цель MSA - добиться низкого зацепления и высокой связанности.

Микросервисы выросли из SOA. Вот в SOA независимость компонентов возведена в абсолют. Вплоть до различных ЯП, используемых системой. Однако это к парадигмам не имеет отношения, так как в SOA для взаимодействия подсистем используется внешний протокол. А MSA, это частный случай сервисной архитектуры, где, кстати говоря, различные методологии вовсе не приветствуются, там просто делается попытка разграничить зоны ответственности физически.

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

И вот это и есть мультипарадигма. Умение воспринимать подходящие под задачу инструменты, как единый контекст.

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

Еще какая абстракция. Или ты пользуешься исключительно интерфейсами, а то, что внутри, делают другие люди? Инкапсуляция же, как я забыл...

Ты все равно будешь использовать процедурку, никуда не денешься. И переключаться придется. Все зависит от границ контекстов, которые ты сам для себя определяешь.

Если ты сейчас попытаешься рассказать мне про контракты, что в ООП можно сначала определить методы, потом их реализовывать, что обуславливает меньшее число "переключений", то я с тобой соглашусь. Но добавлю одну печеньку - ровно тоже самое можно сделать и без объектов. А значит и без ООП.

Кто сказал мешает? Почитай внимательно. Я говорил не столько про запрос, сколько о том, что не всегда выгодно выделять метод или тем более класс (Extract Class) по Фаулеру, чтобы устранить повторы кода. А борьба с повторами, это и есть DRY.

Вовсе не любыми, а вполне аргументированными. С должным уважением (зеленая строчка в моей подписи)

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.