"SOLID" про модули изначально существует, многие почему-то не читали до конца оригинальную статью.

позвольте, но какая именно статья?)

Да, обычно аппологеты SOLID рекомендуют книги дяди Боба «Clean Code» и «Clean Architecture»

Та самая, где было 5 + 3 + 3 принципа. Книги вроде были позже. Сейчас сразу с работы не найду.

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod - в любом случае найти их не проблема.

Скорее уж эта, от 2000 года, которая потом в книжку вошла. Кстати ПОСЛЕ глав с рефакторингом, что как бы показывает ее неоднозначность и соподчиненность https://fi.ort.edu.uy/innovaportal/file/2032/1/design_principles.pdf

Проблема в том что определять что такое модуль, тоже скил. И в процессе эволюции продукта, критерии могут сильно отличаться. SOlid почемуто огульно применяют к классам и объектам, а вот компонентному дизайну мало уделяют внимания.

Спасибо!

Декларативный стиль - это всего лишь стиль высказывания. Это не отличает требования от конструкции. Отличает другое. Если вы написали программу (в любом стиле) и она работает - значит, вы задали конструкцию полностью, места для неопределенности, для дальнейшего конструирования - не осталось. А если вы написали что-то, и есть масса способов довести конструирование до работающей машины (которой пока нет) - значит, вы описали не конструкцию, а, возможно, только требования. Кстати, они могут быть написаны вполне в стиле последовательности действий и изменения состояний, типа "в императивном стиле", оставаясь требованиями.

+1. Вот я РОВНО об этой проблеме в прошлом году делал доклад, увы, нет сил сильно двигать тему вперед. https://bespalchuk.ru/presentations/2020-03-22-%d1%81%d0%be%d0%b5%d0%b4%d0%b8%d0%bd%d1%8f%d1%8f-%d0%bc%d0%b8%d1%80%d1%8b-%d0%b8%d0%bb%d0%b8-devarch-%d0%bd%d0%b0-%d0%b3%d0%be%d1%80%d0%b8%d0%b7%d0%be%d0%bd%d1%82%d0%b5/

ИМХО, это и есть детский дефект мейнстримного ООП, про который я упоминал вчера.
Мотивация вроде была правильная у авторов, но они почему-то поддержали только один уровень инкапсуляции.
В итоге разработчики не могут мыслить на ЯП в терминах крупных runtime подсистем/компонент.
И выстраивают мелкий ровный горох тысяч классов, которые неплохи сами по себе, но не складываются ни во что внятное уровнем выше.

> Если вы написали программу (в любом стиле) и она работает - значит, вы задали конструкцию полностью, места для неопределенности, для дальнейшего конструирования - не осталось.

Под стилем имелась ввиду, вероятно, парадигма. Есть очень важный (хотя и не частый) момент - верифицируемость.

По-моему, единственное верифицированное по максимальному уровню микроядро -- это seL4. Чтобы доказать, что в нём невозможны никакие дедлоки, сделали модель этого ядра на хаскеле (т.е. FP), а потом формально верифицировали.
https://ru.wikipedia.org/wiki/L4_(микроядро)#Верификация

Отличия IMHO не в этом. Оно не синонимичное - типа какая разница - подай с пола яблоко лежащее в 20 см слева от кровати, или - принеси одно из разбросанных на полу яблок. Оно онтологическое. 1) "Директивный" стиль перегружает контур управления - он требует от постановщика задачи быть асом во всех аспектах и учитывать все риски 2) Директивный стиль не допускает интерпретации исполнителем способа решения - он отрицает что исполнитель постоянно учится и может находить другой опыт решения данной задачи 3) Директивный стиль не учитывает риски - когда в процессе возникли какие то изменения - надо эскалировать вопрос наверх 4) Директивный стиль как правило провоцирует встречное сопротивление - мало кому интересно выполнять "чужую волю"  5) Директивный стиль слишком заметен - в условиях контригры оппонентов - даже само вскрытие стратегии противника или догадка о его наличии -  может значительно уменьшить успех его мероприятия, которое станет не "внезапным" 6) Директивный стиль убивает инициативу - зачем думать, если за тебя уже подумали... И пр...    Я не отрицаю - что программисты, как люди рациональные - не любят случайностей. И все хотят разложить по полочкам. Или по крайней мере поуправлять этими вещами вне контура своей ответственности. Вам наверное встречались программисты или архитекторы, которые на прямом серьезе хотели поуправлять даже собственниками и владельцами компании , "наставить их на путь истиный" - а на деле боясь их инициативы, которая могла бы им доставить дискомфорт..   Поэтому я думаю - что директивный стиль при всей понятности - применим только в условиях нехватки времени и в конкретных простых кейсах - типа "тушения пожара"..  Во всех остальных случаях - лучше разумно "пускать на самотек" - выстраивая только самые необходимые границы, но не втягиваясь в микроменеджмент..  Природа уже давно это сделала - даже на человеке. Есть ЦНС - включая головной мозг - который занимается вселенскими проблемами, а есть спинной мозг - который управляет "периферией".. А где не хватает скорости или геометрически трудно проложить нервы - там используется гормональные коммуникации - адреналин мгновенно дойдет до каждой клеточки и органа, быстро разнеся broadcasting message на химическом уровне..

Написал ревью на книгу Ускоряйся https://vvsevolodovich.dev/accelerate-book-review/

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

Так и ООП на уровне анализа нет. На уровне анализа есть, например, бизнес-сущности, инварианты, бизнес-правила, бизнес-процессы. На уровне реализации это все можно положить на любую парадигму или набор парадигм.

Инкапсуляция - это просто частный случай абстракции. А абстракции нужны в любом случае и не зависят от парадигмы.

Объектно ориентированный анализ - это дисциплина такая есть.

Зато уменьшаются затраты на Обучение (настройку) акторов... управление сконцентрировано в одном месте - а дальше уже в зависимости от задачи :) либо оркестрация либо хореография...