SOLID

Придумал, а точнее взял Coupling/Cohesion, вывел из них красивые буквы SOLID и сделал их модными именно Роберт Мартин. Тут ошибки нет.

То есть если метод состоит из 3k+ строк он соответствует этому принципу главное что бы изменения запрашивались от одной роли?

Да, такое возможно. Но маловероятно — обычно методы такого размера притягивают к себе дополнительные ответственности в процессе эволюции кода.

Зачем же тогда отдельно выделены dependency inversion principle?

Потому что не получилась бы красивая аббревиатура :) В SOLID часть принципов прилично накладываются на остальные.

Объект не может о чем-то попросить Аналитика, потому что Аналитик — роль в команде, а не объект и не модуль :-)

Вы бы сначала почитали
SOLID говорит строить зависимости на абстракциях.
Ваши репозитории зависят на AbstractPersistor или PersistorInterface.
В начале реализовали PostgreSQLPersistor который имплементирует абстракцию. Захотелось использовать MariaDB имплементировали MariaPersistor и с помощью dependency injection подменили.
SOLID вам только помогает в этом вопросе

Есть класс Квадрат и есть класс Прямоугольник. Что от чего наследовать?

Какое отношение этот вопрос имеет к статье?

Ну хорошо, попробую ответить на него. В иммутабельном виде Квадрат должен быть наследником Прямоугольника, потому что квадрат — это просто прямоугольник специального вида. В изменяемом виде ни один из этих классов не может быть наследником другого — это нарушит LSP.

Вы читали первоисточники, которые указаны в статье?

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

Цель статьи привлечь внимание и посоветовать ознакомиться с первоисточниками.

Круто, что хоть кто-то открыл эту книжку =)
Еще советую посмотреть видео. Их можно найти.

SRP
DBA тут при том, что есть шлюз к базе, и актором, запрашивающим изменения будет DBA.
То, что вы привели — действительно цитата из книжки, я же привел свою трактовку.

OCP
Определение из статьи — цитата из книжки. Трактовка взята из соответствующего видео с cleancoders.com. Артефакт — это файл, содержащий класс в текстовой форме, dll, и т.п.

LSP
В основном, эта часть опять взята с cleancoders.com

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

Т.е. в реальном мире список окружностей является подтипом списка фигур, но в программной модели с изменяемыми списками это не так.

List<Shape> на List<Circle> заменять точно так же нельзя, потому что List<> — инвариантный обобщенный тип.

Смотрите что было бы, если бы было можно:

void func(List<Shape> list) {
    list.Add(new Rectangle());
}

var list = new List<Circle>(); // В Java будет new ArrayList<Circle>();
foo(list);
Circle c = list[0]; // БАМ! Прямоугольник - не круг.

Виноват тот, кто реализовал DoubleStack.

избегайте глобальных абстракций (List, Hash, etc)

Несколько странный вывод =)
Хорошо бы пользоваться соответствующими интерфейсами, а для их выбора поможет ISP.

На самом деле не факт, что LSP нарушается, если в контракте Stack не заявлено, что pop добавляет один и только один элемент, увеличивая length на 1. Если клиенты Stack не делают предположений как работает стэк, не ожидают, что

l = stack.length();
stack.push(a);
stack.push(b);
assert(l + 2 === stack.length();
assert(b === stack.pop());
assert(a === stack.pop()); 

то нарушения нет.

Смотря что вы называете разработкой. Написать одну версию "под ключ" по подробному ТЗ, сдать и забыть, а если придётся дорабатывать, то вторую версию писать с нуля — тут эти принципы могут удорожить разработку.