Size: a a a

Software Design/Architecture/Zen

2021 June 04

SP

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

SP

Sergey Protko in Software Design/Architecture/Zen
у меня под рукой есть примеры где люди "во имя цели унификации персистенса" мэпят все данные на одну структуру грузят все это дело что бы потом просто имя достать для UI.
источник

MT

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

SP

Sergey Protko in Software Design/Architecture/Zen
ну или начитался статей "как с DDD код писать" :)
источник

MT

Max Trifonov in Software Design/Architecture/Zen
Возможно это им зачем-то надо...
Но мне как то не заходит
источник

SP

Sergey Protko in Software Design/Architecture/Zen
у них мотивация та же что и тут обсуждается - "но как же это - одна табличка один репозиторий"
источник

MT

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

ST

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

SP

Sergey Protko in Software Design/Architecture/Zen
я любитель херак и в прод но у меня есть jsonb и массивчики для такого и то что ты описываешь это хз как надо себя не любить
источник

SP

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

SP

Sergey Protko in Software Design/Architecture/Zen
что до нормализации бд - мне ок что у меня часть many-to-many связей просто jsonb массивчиками реализовано
источник

IR

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

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

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

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

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

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

ST

Serguei Tarassov in Software Design/Architecture/Zen
jsonb и "массивчики" - те же яйца, вид сбоку, особенно в случае спиcка ID.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
зато оч удобно и можно index only scan мутить.
источник

MT

Max Trifonov in Software Design/Architecture/Zen
В голову лезет saga и events
источник

SP

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

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

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

IR

I Raimbayev in Software Design/Architecture/Zen
Немного не то. Я сейчас именно с точки зрения внешнего API, чтобы было максимально удобно для внешних клиентов =)
источник

MT

Max Trifonov in Software Design/Architecture/Zen
Тогда Сергей был прав, а я прочитал не в том ключе
источник

SP

Sergey Protko in Software Design/Architecture/Zen
это надо к требованиям к клиенту уже, для этого надо еще рассмотреть вопросы "а че делать если запрос зафэйлился".
источник

SP

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