Коллеги были на местном Владивостокском митапе не так давно - очень хвалили выступление представителя Монастырева.
Судя по некоторым их комментариям, услышали они "то же, о чём и ты говоришь". То есть вроде я говорю о том же.
Но сегодня увидел ссылочку на презентацию Дениса Павлова, ознакомился и сел на жопу писать им письмо - дабы поправить положение.

Но подумал, ещё кому-то может пригодиться. Надеюсь, Денис не сильно обидится - со многим в его презентации согласен, да и думаю, хорошо когда твои мысли провоцируют и других (в данном случае меня) задуматься.

N+1-й (точнее, 0-й) принцип в любой системе из N принципов должен говорить о соблюдении разумной достаточности при использовании этой системы.
Исключение: системы алгоритмов для станков с числовым управлением и прочих роботов.

Ближе к Каше и ООП:

1. Каше, это не такая же объектная среда, как и остальные . И SOLID - это лишь один из способов упорядочения разработки ОО-дизайна. Вообще, понятие ОО-среды сомнительно. Сегодня само определение ООП довольно размыто, не говоря уже о среде. Гораздо ближе к программированию в нашей СУБД подходит такое определение (мы так работаем):
википедия...это программирование, сфокусированное на данных, причем данные и поведение неразрывно связаны между собой. Вместе данные и поведение представляют собой класс. Соответственно в языках, основанных на понятии «класс», все объекты разделены на два основных типа — классы и экземпляры. Класс определяет структуру и функциональность (поведение), одинаковую для всех экземпляров данного класса. Экземпляр является носителем данных — то есть обладает состоянием, меняющимся в соответствии с поведением, заданным классом.
Синергетику я изучал аж целый курс, поэтому могу ответственно сказать, что такой подход отвечает мощной синергией:
Хорошо реализованная модель предметной области дает правильный отклик на воздействия, не описанные в требованиях и непредусмотренные архитектором и программистом.
Это довольно частая приятная неожиданность в моей работе.

2. Многие шаблоны ООП либо уже реализованы в самой СУБД и программисту о них знать не нужно (фабрика, активная запись и проч.), либо утеряли значимость (синглтон). Впрочем, нам тут далеко до Лиспа, где 16 из 23 "бандитских" шаблонов по некоторым утверждениям "незаметны". Вместе с тем у многих нынешних разработчиков напрочь отсутствует различение производства программ от создания информационных систем .
Реальная ситуацияПриходят два "разработчика" "со знанием ООП" и предлагают за месяц "автоматизировать" участок бизнеса. На вопросы об интеграции и поддержки этого "реально крутого продукта" впадают в ступор. Т.е. вообще не готовы. Т.е. в их системе нет шаблона о звонке в 3 часа ночи, когда максимум за 20 минут нужно разрулить проблему софта, из-за которой встало движение в половине города.В итоге ради очень сомнительного (на мой взгляд, вредного в случае с Каше) принципа "единственной обязанности", парни готовы писать три класса по 10 строк вместо одного с пятнадцатью. Кто не понял где смеяться, подумайте о том, сколько усилий потом уйдет на поддержку такого "порядка". По моим субъективным оценкам, именно содержание кода является главной проблемой отрасли сегодня. Особенно для кода, который типа "поставили", типа "в коробке". А чрезмерная страсть к шаблонам чаще усложняет такую работу, чем помогает. Вместо того, чтобы в коде увидеть комментарий вида "тут пчёлка ведёт себя как трутень" мы видим "применил к пчеле шаблон "фасад". Ёпт, ну сразу всё понятно - чож!

В Каше очень неплохо УЖЕ реализованы многие замечательные шаблоны, так что программист-прикладник может с удовольствием, в заботе о бизнесе и пользователе, заняться реализацией модели предметной области, заботясь о минимуме обязательных условий (типа сильного зацепления, слабого связывания и применения синтетики/абстракций).

3. Думать абстракциями неплохо. Для системного программиста просто необходимо. Но когда простой прикладник (типа нас с вами) начинает изобретать абстракции, это редко приводит к хорошему. Абстракции и так уже с излишком есть, ищите в %-классах. Если не находите нужной, значит с вероятностью 99% она не нужна! Перемудрили. Меняйте условия задачи или ищите более простое решение. То же касается всевозможных "полезных" библиотек. Например макросов. Вы хотите коллегам доказать что изобрели новый язык? И приучить их к нему? Упрётесь в то, что окружающие "по образу и подобию" наизобретают своих (только им удобных) абстракций и будете вы потом разбираться, почему одна и та же функциональность параллельно существует в методах трёх "полезных" классов и пяти макросах. Я противник абстракций - на этапе проектирования совершенно точно их не должно появляться. Если через три года эксплуатации вы пришли к выводу, что некая абстракция нужна, Тогда можно о ней подумать.
Примечание: "документ", "расходный документ" и "расходный ордер" - это не абстракции, а одна из цепочек в иерархии классов модели предметной области.

4. Поскольку основной идеологией разработки у нас является реализация модели предметной области, наименования пакетов должны соответствовать иерархии её объектов . В основном. См. нулевой принцип. На модули же могут быть поделены классы интерфейсов или определены веб-сервисы.

5. Считаю утопией разговоры о неких классах "бизнес-логики" или реализации "бизнес-процессов". Бизнес-логика размазана по требованиям к системе, нормирующим документам (положениям, приказам, договорам и т.п.), классам данных (объектам предметной области), пользовательским и программным интерфейсам, смежным и параллельным системам и прочему . Например, часть её в любом случае останется лишь в головах исполнителей или руководителей или(!) программистов. Так устроена жизнь и всё формализовать невозможно. Да и ненужно.

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

С уважением и надеждой на понимание. Колесов.