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

у меня под рукой есть примеры где люди "во имя цели унификации персистенса" мэпят все данные на одну структуру грузят все это дело что бы потом просто имя достать для UI.

Просто мысль из того, может я ошибаюсь, у человека не ложиться это в 1:1 +/- (иначе думаю вопроса небыло у него)

ну или начитался статей "как с DDD код писать" :)

Возможно это им зачем-то надо...
Но мне как то не заходит

у них мотивация та же что и тут обсуждается - "но как же это - одна табличка один репозиторий"

Я не приверженец репозитория
Только в случае агрегата (держим целостность и вопрос в write, транзации)
Согласен с тобой по поводу read операций, любых, что лучше сервисы...
Но у себя стараюсь это перекрыть одной "точкой ответсвенности" именно по мапингу

Не совсем так. Если большинство объектов персистентные, то схема меняется и факторизуется вместе с ними. Избежать этого - накапливать техдолг в виде денормализованной БД. Любители "херак-и-в-прод" любят предлагать "решения" типа, "давайте просто расширим колонку и будем хранить в ней список через запятую"

я любитель херак и в прод но у меня есть jsonb и массивчики для такого и то что ты описываешь это хз как надо себя не любить

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

что до нормализации бд - мне ок что у меня часть many-to-many связей просто jsonb массивчиками реализовано

Добрый вечер!
Подскажите, пожалуйста, что можно глянуть / почитать про проектирование API для мноступенчатых процессов?

Например, у нас был API для добавления заказа, все просто, обычный rest API, post order.

Теперь процесс усложнился.
Клиент создаёт заказ, получает идентификатор. Через некоторое время с ним связывается менеджер и просит подтвердить/уточнить моменты. Если все ок, высылаем sms, он подтверждает этот заказ. Спустя время он должен ещё загрузить некие данные к этому заказу, пусть будет некое разрешение, и т.д.

В общем, над сущностью совершают несколько шагов операции. При этом это могут быть разные пользователи и роли.

Думал в сторону чего-то вроде :
POST api/orders
POST api/orders/{id}/confirm
POST api/orders/{id}/upload_landing_permission
...

Насколько это правильно?

jsonb и "массивчики" - те же яйца, вид сбоку, особенно в случае спиcка ID.

зато оч удобно и можно index only scan мутить.

В голову лезет saga и events

REST это не про круд. Урлы это не про сущности. POST это не про "создание" а про неидемпотентные операции. Можно апдейтить POST-ом (инкремент) можно создавать PUT-ом (если есть какой ключ для идемпотентности операции).

Потому все что угодно можно делать POST-ом (просто все не гарантирует идемпотентности и это может усложнять клиент для ретраев) и урлы просто должны предоставлять уникальный идентификатор к ресурсу (что бы кэшировать удобно было)

Если не комфортно мысленно представь что /orders/{id}/confirm это "создание подтверждения"

Немного не то. Я сейчас именно с точки зрения внешнего API, чтобы было максимально удобно для внешних клиентов =)

Тогда Сергей был прав, а я прочитал не в том ключе

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

ну то есть ты ж мысленно можешь представить вот как ты пишешь api клиент для своей апишки (а еще лучше - ты ж тесты пишешь?). Вот и сможешь сказать удобно или нет