А кто-то нападает на SOLID для elixir?

SOLID в любой парадигме норм, пока ты не начинаешь каждую буковку реализовывать. Это набор принципов и правил, которые можно использовать, но не надо пихать в каждую дырку. Собственно, как и паттерны всякие

single responsibility и interface segregation - языконезависимые принципы
open-close и dependency inversion - это больше про ООП, D - так вообще про то как собрать джунгли для гориллы, держащей банан. хотя и в эликсире можно делать dependency injection, но код становится сразу менее читаемым.
Liskov substitution я вот прям так в эликсире не встречал, он не универсален и скорее всего не имеет смысла где нет наследования типов

Вообще если говорить не об аланкеевском, а о жабаподобном ООП, то суть его - в полиморфизме посредством подмены объектов-исполнителей.

So our reductive definition of OO is:

The technique of using dynamic polymorphism to call functions without the source code of the caller depending upon the source code of the callee.

https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html

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

Но, привычное для ООП наследование в каком-то виде в эликсире тоже есть, макросом using, так что принцип тоже тут имеет место быть.

а Liskov substitution можно реализовать с помощью паттернматчинга функций, просто заход с другой стороны, ты делаешь и новые структуры и функцию, способную их обрабатывать

У меня может вопрос не по теме. Но, если будут мнения мне интересно.

Я первый раз работаю с microservices architecture. Микросервиссы обещаются между собой посредством Amazon SQS. База на сервисы одна, но таблицы разделены при помощи схем.

Как это добро разрабатывать локально?

Использовать что-то типа Minikube?

Потом, если все сервисы смотрят в одну базу, то рано или поздно заканчиваются connections. А в Amazon RDS есть лимит на вроде 200 соединений.  Использовать что-то типа PGBouncer?

Блин, пойду перечитаю DHH про монолиты)

База должны быть разная так-то

Да, архитектурно наверное.

Вообще базы разные должны быть. Обычно в микросервисные проекты завозят абстракции над транспортами типа mq или pubsub

Да, у нас PubSub посредством Amazon SQS, но непонятно как поднимать локальное окружение.

Может просто не использовать одну базу? Типа можно завести master-slave

Абстрагируйся от Amazon SQS в какой-то бихевиор, а потом для локальной разработки и тестов используй встроенные pubsub, например, на pg2

Дай пожалуйста ссылку на pg2?

Поищи в доках эрланга

Бертран Мейер в основном известен как основоположник термина Принцип открытости/закрытости, который появился в 1988 году в его книге Object-Oriented Software Construction, отвечая на вопрос:

«Как можно разработать проект, устойчивый к изменениям, срок жизни которых превышает срок существования первой версии проекта?».

Это примерно про "фиксируем API на версии 1 и не меняем, все изменения пихаем в версию 2".

Да, как принцип вообще это ок. А в жабаподобном ООП не ок, потому что оопэшники пытаются применить его к наследованию классов (а не модульного API). А наследование противоречит принципу инкапсуляции и неизбежно приводит к проблемам на проекте. То есть конкретно к классовому наследованию этот принцип малоприменим.

Спасибо за помощь.