@vshapenko ща играю с интерпретатором. Ты делаешь 1 сет инструкций на 1 сущность или на 1 боундед контекст?

@vshapenko ща играю с интерпретатором. Ты делаешь 1 сет инструкций на 1 сущность или на 1 боундед контекст?

Разверни суждение

Сет инструкций — это типа DU, который по сути представляет дерево исполнения программы. Кажется, ты это называл CardProxy в своем примере. Выглядит примерно так: type CardInstruction<'a> = | GetCard of CardNumber * (Card -> CardInstruction<'a>) | SaveCard of Card * (unit -> CardInstruction<'a>) | Stop of 'a Проблема тут в том, что нужны другие сущности, например, аккаунт инфа или сам юзер. Поэтому тут нужно либо расширять этот ДУ кейсами GetAccountInfo и тд либо делать 1 штуку на весь баундед контекст, в котором будет вообще все. Я вот склоняюсь ко второму варианту

Смари

У тебя есть контекст исполнения

Который все умеет

Дальше у тебя есть сет инструкций

делаю по примеру отсюда https://stackoverflow.com/a/51262899/6198294

А, ты во фри монады упоролся

нене

в ответе чисто интепретатор

Я пытаюсь оценить трудозатраты на всю эту обвязку — мб они будут не сильно велики и тогда это будет лучше, чем просто паршл аппликейшн

Тэкс, Card->CardInstruction, как я понимаю, задает следующий стейт

да

ВОт что делает unit->CardInstruction, неясно

типа сохраняет в базу. Для того, чтобы потом в do!... пихать это

Этого не должно быть в инструкциях

В инструкциях по идее должно быть то, что я хочу сделать и то, что хочу в теории вернуть

Хотя насчет вернуть у меня сомнения

куда ж тогда инжектить сейв в бд? Или типа ты сохраняешь то, что вернул, снаружи?

Идея в том, что у меня есть некий ctx

Куда я передаю этот сет инструкций

И он уже сохраняет в бд и прочее

ну этот некий контекст — это интепретатор твоего дерева исполнения?

Ага

Но дерево там должно быть тупое

ну, так это не значит, что не нужно делать сейв-узел в дереве

то есть дерево останется чистой структурой

Ты делаешь AddCard

Результат каждой операции по идее должен быть сохранен в базу

Если мы про финтех

допустим

Т.е. каждая инструкция у меня порождает набор некоторых атомарных операций

Например, сохранить в базе

Взять из базы по айдишнику

В нашем случае это в общем-то три операции, insert,delete,get

Например, AddCard превращается в цепочку операции сохранения в базе плюс, возможно, возврат какого-то результата

В нашем случае это в общем-то три операции, insert,delete,get

ну то есть у тебя уже в инструкциях должны быть заложены эти операции, так?

ну то есть у тебя уже в инструкциях должны быть заложены эти операции, так?

Зачем

Это операции, относяциеся к конкретной реализации бд

да, я говорю не про имплементацию

Или моего контекста

а про плейсхолдер для них в дереве

Плейсхолдер там не нужен

На разных контекстах может быть разная логика исполнения

а можешь набросать гист для простого сценария?

Типа взять по айдишнику - обновить - сохранить

Ну ща попробуем

Чет наговнякал

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

https://gist.github.com/vshapenko/d7f5e068c18c06506a61ddd6079c1ce0

Идея требует доведения до ума

Идея требует доведения до ума

Ум требует доведения до идеи

Ум требует доведения до идеи

Это тоже

че-то не понял, зачем там тип Domain

че-то не понял, зачем там тип Domain

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

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

Экшн ничо про бд не знает

Это условно бизнес кейсы

типа бизнес-операции? В духе "активируй карту", "полони баланс" и тд?

типа бизнес-операции? В духе "активируй карту", "полони баланс" и тд?

Угу

ок, 1 такой тип на 1 баундед контекст?

Но тут надо не проебаться с уровнем детализации

Ща, я попытаюсь вспомнить, шо есть bounded context

Так, почитал

Да

Один тип на контекст

ок, с этим понятно. Как в этой схеме собирается реальный пайплайн? Id -> Card -> UpdatedCard -> CardModel?

Судя по всему, руками

Ну т.е. на самом деле зависит от того, насколько нам дорого на каждом этапе из базы доставать

Так, чет меня уносить стало не в ту ступь, походу

Еще чуть-чуть, и начну нести херню в массы

то есть на самом верху объявляешь пачку функций processAction, и на самом же верхнем слое собираешь что-то типа let processPayment p = getUser p.User getCard p.Card и тд?

то есть на самом верху объявляешь пачку функций processAction, и на самом же верхнем слое собираешь что-то типа let processPayment p = getUser p.User getCard p.Card и тд?

Идея была такая, да

мне не нравится, что определение порядка действий уходит из доменного слоя

Ну в разных контекстах разный порядок действий

поясни

Нам главное, чтобы операции бизнеса в правильном порядке шли

да, но тут получается, что порядок бизнес операций определяется за пределами бизнес-слоя

А внутри операции нам в целом неважно, начитываем мы сначала аккаунт отправителя или получателя