Ты их не можешь уже последовательно применять

Так разбивайте эту логику на части поменьше и не пытайтесь за один запрос сделать всё

Поэтому нужно применять всё сразу, и все сразу валидировать

Ну так мы ж это обсуждаем в контексте жсонапи

Если у вас есть бизнес правило по валидации то вы его никак не уберёте 🤷‍♂️

Который как раз предполагает что всю сущность+релейшены можно вытягивать за один запрос(что ещё норм), и обновлять, если на запись

Да, ещё раз, при последовательных маленьких операциях будет много методов с парой проверок

При одной большой будет много проверок в одном

Ну так это проблема не json api

В общем я может туплю, но так и не понял что не устраивает(

Так суть жсонапи в том чтобы эти операции объеденить

Вот эту фразу не понял

Которые по хорошему то разбивать надо

Какие атомации?

справедливо ли утверждение? DDD - методология разработки ориентированная на решение проблем конкретной предметной области (domain), для этого она предлагает ввести "повсеместный язык" (UBIQUITOUS LANGUAGE) для упрощения коммуникаций вовлеченных людей (технари - не технари), так же методология обязывает вынесение сложной логики (если таковая имеется) в отдельный слой (доменный) приложения, а так же предлагает (но не обязывает) использовать ряд технических шаблонов (Entity, Value Object,modules, Aggregates и т.п. )

Всё так. Только вынесение методология не обязывает делать, а предлагает

не важно что внутри (ООП, не ООП),не важно какой технологический стек, не важно насколько проэкт большой или маленький. Тоже все верно?

Для маленького это не нужно. Остальное всё так

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

Непонятно может быть везде. Это не критерий