если очень упрощать...

"write model" - то что использует система для изменения своего стэйта. "модель как стэйт меняется". "Read model" - то что используют внешние экторы (люди или внешние системы) для принятия решений че делать дальше. "модель принятия решений этих экторов"

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

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

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

хотя я не знаю, зависит от того шо такое "бизнес-логика", наверное 🤔

если есть логика и ты эту логику обсуждаешь с бизнесом наверное это бизнес логика?)

- коммуникации - хм.. это странно звучит, учитывая что доменный слой и вообще доменная модель - это в первую очередь ubiquitous language, то есть единый язык для проекта, что должно улучшать коммуникацию, а не ухудшать.

- баги. Тоже странно. Вынесенный в отдельный слой и в ядро домен - является самой ценной,  жестко валидируемой и наиболее протестированной частью приложения... Это наоборот должно обеспечить минимум багов.

- мердж-конфликты - непонятно, они в любом процессе, где >1 человека работают есть

- сложности с тестированием - непонятно какого рода. Пока что все тестируется - и ядро отдельно и проект с ядром вместе. CI гоняет тесты.

- насчет скейлинга - здесь наверное можно согласить, но это вопрос компетенций. При наличии желания и опытного члена в команде въехать в такой подход не сложно. А вот с желанием по моим наблюдениям - проблемы. Людям привычный хуячить как хуячил 10 лет

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

> очередь ubiquitous language, то есть единый язык для проекта

вопервых он единый не в пределах всего  "проекта" а только одного bounded context. Вполне нормально когда в большой компании один и тот же термин означает разные вещи для разных людей. Мы не пытаемся заставить людей разговаривать на одном языке в пределах всего бизнеса, мы пытаемся при взаимодействии с подразделениями этого бизнеса говорить с ними на одном языке. А между - там ужас и хаос.

> Вынесенный в отдельный слой и в ядро домен - является самой ценной,  жестко валидируемой и наиболее протестированной частью приложения

не все под домены одинаково ценны и далеко не все являются такими как ты описал.

> - мердж-конфликты - непонятно, они в любом процессе, где >1 человека работают есть

Ну вот тут я тож не понял причем тут слои или не слои - это больше про continious integration/trunk based development и про information hiding (возможность работу паралелить по сути за счет изоляции частей). Может быть по этому... слои в целом с informatjon hiding вообще не помогают. Ну может быть если мы говорим о классическом кейсе когда верстальщики/программисты разделение какое...

> - сложности с тестированием - непонятно какого рода. Пока что все тестируется - и ядро отдельно и проект с ядром вместе. CI гоняет тесты.

до тех пор пока у тебя ядро маленькое. Если у тебя на всю систему "одно ядро" - скорее всего будет плохо. Не факт конечно но...

> А вот с желанием по моим наблюдениям - проблемы. Людям привычный хуячить как хуячил 10 лет

эт да

ну показать id или картинку это не логика. Логика это if-ы и прочие преобразования данных.

Никогда с бизнесом поиск не обсуждал?)

мы ж про слои говорили. Я про то, что без вертикальной декомпозиции кохижен будет низкий, а каплинг высокий.
Как следствие - чтобы сделать одну фичу - надо залезть в другую фичу. Тогда надо договориться с Васяном, который пилит эту фичу - лишние коммуникации. А если таких Васянов 10? Комбинаторный взрыв.
Мерж-конфликты то же самое - залезаем при изменениях на чужой код и разматываем километровые мержи, это я даже сам проходил на практике. Больно, дорого, легко сделать ошибку (желательно мержить вместе :D опять же коммуникации). Прикол в том, что мерж-конфликты можно свести к минимуму при вертикальной декомпозиции.
Баги - если мы лазим в 10 фич, чтобы запилить 11-ую, высока вероятность, что какая-то из этих 10-ти сломается. Вот эта штука повлияет на вон ту штуку и чё-нить отвалится. "Почему это у нас при приоткрывании дверцы холодильника перестаёт работать слив унитаза?"
Тестирование - попробуй протестируй код с высоким каплингом, посмотрим сколько прекондишенов будет в тестах и как ты через неделю будешь их читать. Как часто они будут ломаться, насколько они будут изолированы (спойлер - никак не изолированы, ты будешь сто лет искать где именно сломалось) и как быстро команда придёт к "ну тесты дорого, давайте не будем их писать, чёт от них только боль (заодно передаём привет пункту Баги и проблемам CI)".

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

Если у тебя все знаю с кем надо общаться и кто за что отвечает - скорее всего у тебя это вертикальное разделение будет само собой вырисовываться

красота всей этой херни проявляются когда разные люди просят тебя сделать дублирующийся функционал)

конфликты в требованиях всякие...

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

и что-то у нас какая-то инверсия понятий, не?
вертикальная декомпозиция, - это же как раз слои,
горизонтальная декомпозиция - это модули/feature/bounded-context
У меня складывается ощущение, что под вертикальной композицией вы именно разделение фич понимаете? Или я что-то не так понимаю?

ну просто ты как-то выделяешь, что слои - это важно, а остальное как-то не упомянул. Может быть ты думаешь, что это само собой разумеющееся, но на практике оно обычно не так. Про слои люди ещё обычно думают, а вот про остальное - не особо.
ну да, похоже у нас противоположные термины

слои - горизонталь (ui -> domain -> persistance), вертикально фичи. Можно наоборот конечно но стоит договориться)

про "в куче" - если есть только разделение на слои то внутри слоев обычно тендеция к "куче".

В целом вернемся к вопросу - какая пользва от того что ты например определил "слой" для read model? Или даже по другому вопрос задам - напомни для чего именно мы отделяем персистенс от домена? Что конкретно мы там отделяем

персистенс от домена отделяется
1) потому что хранение и логика по моему убеждению это разные, не связанные друг с другом вещи.
2) потому что в одном проекте, использующем домен, eloquent, а во втором doctrine. Домен зависящий от конкретного инструмента для доступа к данным - связывает руки.

Домен, отделённый от хранилища, упрощает модульное тестирование, нет?

И, кстати, код бизнес-логики становится почище, нет всяких технических деталей