имплементация репозитория это уже инфраструктура.

Для меня доменная модель это value object или агрегат, сущность с бизнес логикой его взаимодействий.

Разделение на домен, инфраструктуру мне не понятно. Вот раздение по SRP - есть понимание.

то что ты перечислил - элементы модели. Модель - это нечто большее.

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

то есть все эти интерфейсы репозиториев, доменные сервисы и тд. - часть бизнес модели

вот рядом с SRP есть такие принципы как ISP и DIP. В предыдущих редакциях (до того как это называлось solid) было еще два полезных принципа - принцип стабильных зависимостей (Stable dependency principle) и принцип абстрактных зависимостей (abstract dependency principle)

соблюдая все это (в том числе и SRP) ты получишь разделение на инфраструктуру и домен по итогу. Хочешь ты того или нет.

насколько это раздеение будет выражено явно в коде - хз, но в целом штуки которые в базу ходят и логика у тебя будут разделены

как раз думала, ISP немног смахивает на частный случай SRP

Да, читал вот тут http://webcache.googleusercontent.com/search?q=cache:j4SgC9m-aIUJ:butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod&hl=en&gl=ru&strip=1&vwsrc=0
Ток кэш сохранился(
Но инфраструктура слишком большое понятие, там внутри тоже много деление может быть же...

цель у SOLID какая? Уменьшить каскад изменений. То есть по факту добиться OCP. Ну или как минимум если уж изменения случилось что бы затронуло что-то одно - SRP. Как этого добиться? Можно под клиентский код специализированные интерфейсы делать (ISP) и менять направления зависимостей так что бы оно всегда указывало от менее стабильных к более стабильным модулям (DIP). Ну и если ты начала обмазываться интерфейсами то LSP поможет убедиться что контракты выбраны правильно.

как и в домене, да.

домен вообще на контексты дробится) или на поддомены

это все условные названия "слоев". Слои это виртуальный концепт. тебя никто не заставляет прям пакеты по слоям делать. Достаточно что бы штуки относящиеся к разным слоям были в разных файлах. А может даже и это не совсем обязательно и важнее смотреть на то кто от кого зависит.

да, для соблюдения OCP на этапе проектирования нужно знать будущее. Можно пробовать "придумать будущее" - это в целом работает но скорее всего рано или поздно этот принцип будет нарушен. С SRP похожая история - что бы хорошо понимать соблюдает твой код SRP или нет нужно оч хорошо понимать откуда изменения приходят, почему они приходят и кто от них блага получает. Эти принципы больше подходят для того что бы драйвить рефакторинг. Тот рефактоинг который "пописал код часик - посмотрел что написал отрефактоил" а не "переебашить пол проекта"

SRP тоже не однозначно понимается разными людьми и имеет не одну грань понимания. Недавно встретил заметку о не единственной ответственности, а о единственности обслуживания, но сейчас найти не могу.
Зато нашел это, где тоже специфическое понимание, на примере класса контекста, котрый может разростись до god объекта...
https://medium.com/android-news/single-responsibility-principle-and-context-60e39a28e5bd#:~:text=Single%20Responsibility%20Principle%20(SRP)%3A,only%20one%2C%20reason%20to%20change.&text=Following%20SRP%20is%20difficult%20because,future%2C%20when%20requirements%20actually%20change.

Мне один чел затирал, что SRP это очень однозначный и прямой принцип, где код можно на 100% разделить как “единичные отвественности”

а ещё  завязываются на "класс", а  Боб Мартин про модули\компоненты

в clean architecture трактовка в этом духе

Если маленький проект, то почему нет?