Инверсия зависимостей не меняет контракт

Ты типо спрашиваешь почему все не сделали олну фцию save()?

Пример - у нас 2 юзкейса, которые вызываются подряд в контроллере, почему нет. В одном например мы флаш не вызвали. А во втором вызвали. Почему флаш второго хэндлера сбрасывает данные первого в БД?

Приложение говорит сохрани мне заказ. Почему контракт должен отличаться для инмемеори, для эластики, для мускула?

> Пример - у нас 2 юзкейса, которые вызываются подряд в контроллере, почему нет Потому нет, что завтра первый кейс сработал, в SQL платёж списал и письмо отправил, а второй отвалился из-за недоступности API склада или службы доставки и товар не отправил. В итоге дёрнув два или три кейса из контроллера вы попали на геморрой, что надо всё вручную исправлять. Потому как только появляются операции подряд, так сразу будет хана консистентности. Особенно если у них агрегаты в разных БД. И если юзкейсы к сторонним сервисам обращаются, которые могут часто падать. Надёжность обеспечат одиночные атомарные действия, управляемые сагами через очередь с повторами и компенсирующими операциями.

Так напиши сервис как я говорил и приложение не будет иметь дело с слоем сохрания вообще. А только твой сервис

Интерфейс

Согласен в идеале сага, но факт в том, что при глоабльном флаше, один контекст сбрасывает накопленные данные второго

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

А какой операции? У нас операция с фронта сохрани форму на миллион полей, которые у нас 5 контектсов и 5 отдельных юзкейсов. Мини BFF

Увольте человека, кто такую CRUD-форму сделал. Наймите другого, который её разделит по задачам.

Почему фронт зависит от контекстов бэка или наоборот?

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

Ок уволили, сделали 5 эндпоинтов и 5 форм. Потом мы поняли, что один из этих контекстов еще большой. И еще разделили на 2. Фронту опять задача, подстраиваться под бэк и опять когото увольнять?

Так я же не говорю, как это сделать, я говорю, что если 2 юзкейса без саги, и например в первом не флашнули из-за бага (тупо забыли), то второй контекст при своем флаше сбросит в БД данные первого. Ну фигня какая то, сайд эффект

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

Мой любимый кейс: фрма редактирования профиля и в ней ФИО и чекбоксы для управления оповещениями

Ну и зачем их одной формой делать? Сделать форму для имени и фамилии с кнопкой сохранения. А под ней список переключателей с отправкой по onChange.

Почему бэк диктует как делать ui/ux ?

Это не бэк диктует, а здравый смысл UX

Это ваш здравый смысл, здравый смысл дизайнера и кто за это отвечает может быть другим

Дизайнер как раз проектирует удобство UX и в идеале Task Based UI. Чтобы всё было интуитивно понятно по смыслу и просто на каждом шаге. Заполнять имя собаки, номер мопеда, адрес доставки, девичью фамилию и уведомления в одной форме на 100+ порой обязательных полей - это весьма талантливый дизайнер.

Почему мы вообще завели разговор про фронт? Мы что, зависим от него? Мы имеем порты и можем подстроить любой адаптер

Пусть будет "талантливый дизайнер". Значит наш бэк такого не может осилить и все, мы уходим с проекта?)

Потому что вы написали выше, что это фронтендер так решил отправлять кучу несвязных данных на один эндпоинт. Он у вас пуп земли и под него вы все должны подстраиваться, а не наоборот. А то обидится, если ему лишнюю таску закинут :) А я говорю, что фронтендер с бэкендером, заказчиком и менеджером взаимодействовать и продумывать сценарии и юзкейсы должны всегда, чтобы повышать удобство пользования развивающимся продуктом. Была раньше форма регистрации в два поля и люди это делали с лёгкостью, а теперь полей стало уже девять и её стали бояться - можно посовещаться и сделать форму трёхшаговой по три поля. Фронтендер разбил форму на три и бэкендер сделал три отдельных эндпоинта. Потом и таких шагов стало шесть и мало кто осиливает заполнить всё до конца - переделываем на отложенное заполнение. Регистрацию делаем минимальной по почте и паролю, а потом только в момент первого заказа просим дозаполнить имя и телефон. Фронтендер перепилил фронт, бэкендер переписал эндпоинты.

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

Ну вот они решили, что один чекбокс и одно поле с ФИО не стоит того чтобы дробить на несколько вкладок.

Так уж и быть, сэкономлю месяц работы вам и вашему фронтендеру: <h2>Настройки</h2> <input type="string" name="fio" onchange={ (e) => api.patch('/name', {fio: e.target.value}) } /> <input type="checkbox" name="notifications" onchange={ (e) => api.put('/notifications', e.target.checked) } /> Разбил на контексты, добился консистентности и избавил от переусложнения сагами. В ходе доработки ни один дизайнер не пострадал :)

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

Это не наши контексты, а доменные (бизнесовые). Они не только бэкендеров касаются. Фронтендеры тоже люди и тоже должны страдать :)

Ну про страдать норм)) Решение понятное сразу было, но с нимне соглашусь, это не удобно, мы снова что то поменяем (объединим/разделим) - опять фронту менять

Ну и в случае BFF может всю форму принимать в свой идеальный BFF на /settings и из него уже в два наших модуля или микросервиса два запроса на /name и /notifications отправлять.

Фронтендщики вообще наверное мечтают чтобы был один эндпоинт куда весь стейт приложения сохраняется и все

Да, и вот и мы пришли к тому, что в 1 контрллере 2 экшена ))

И получили ту же потенциальную проблему, что один запрос из BFF вглубь ушёл успешно, а второй отвалился с ошибкой. В итоге половина полей формы сохранилась, а половина нет. Теперь фронетендеру с этим надо что-то делать.

Так вопрос то был не о том, проблема в том, что если таких 2 экшена, и в первом отсуствует флаш вообще, но он есть во втором - то он закроет изменения обоих контекстов. Т.е. один контекст сохраняет своим экшеном данные другого. Странный сайд эффект. Поэтому и говорю, что единый флаш - странная штука с точки зрения архитектуры, если капнуть в такие вещи

А ответ был о том, что с точки зрения архитектуры единый флаш удобен для атомарного оборачивания им снаружи одной операции с одним контекстом, чтобы одной транзакцией сохранить в БД изменённый агрегат, его события и ключ идемпотентности если эта операция выполнилась успешно. И неудобен если его кто-то использует для нескольких действий. Тогда да, получаем сайд-эффекты взаимного сохранения и вопрос с тем, что делать если выполнились только две операции из трёх.

А почему (например) с фронта не отправлять разные куски данных на разные эндпоинты?

А почему (например) с фронта не отправлять разные куски данных на разные эндпоинты?

Я щя технологию придумаю. Назову ее graphql

в очередь! я её уже придумал!!!