кажется, грокнул CQRS. но может кажется
расскажи? и сам обычно лучше понимаешь, когда рассказываешь, и окружающим полезно. ‎- адский хардлайн в засаде
значит так. я случайно читал по дороге на работу вот этот тьюториал: http://cqrs.nu/tutorial/cs/01-design и там в первых двух частях рассказывается, как мы из предметной области дистиллируем события и команды, и постепенно реализуем в агрегате обработку команд и рассылку событий (про DDD я пока тоже знаю весьма понаслышке) ‎- волна бургерных
дочитав вторую часть, я попытался представить себе веб-приложение, сделанное на этой модели, которая живёт в памяти, и подумал, что наверное можно сохранение в базу повесить на события, и зачитывать оттуда модель при старте приложения ‎- волна бургерных
и тут я открыл третью часть http://cqrs.nu/tutorial/cs/03-read-models и там написано ровно такое: делаем отдельную read model, у которой мы данные спрашиваем, она апдейтится по событиям от командной модели, и заодно может делать всякий housekeeping типа персистенса ‎- волна бургерных
в этот момент у меня появился проблеск понимания, но тут я пришёл на работу, и дальше эту мысль ещё не думал ‎- волна бургерных
а я вот открыл part 1, и они там говорят, что операции у них умеют exceptions кидать. in my book, это возвращение значения, такое Maybe Error. ‎- 9000
нет, исключения от команд - это техническая штука, они не про бизнес, а про (примерно) удалось транзакцию закоммитить, или надо повторить/обработать откат ‎- волна бургерных
^^ ну нужен же какой-то способ не принимать операцию вообще? вот это он. ‎- сосиски супремасиски
как раз в этом месте лучше всего понятно, что это скелет, и в любом приложении тут будет прикручена подходящая стратегия, или оно быстро развалится ‎- волна бургерных
описываемый фреймворк позволяет определять машины состояний, но как-то очень через жопу :) ‎- сосиски супремасиски
Ответ "не хватило денег" — это разве техническая деталь, неинтересная бизнес-логике? Конкретно MustPayEnough. ‎- 9000
^ это как раз мне не нравится, потому что смешивает уровни, я бы всё-таки это на событиях делал, наверное. но вообще много тут кажется накрученным ради накрутки ‎- волна бургерных
а по-моему нормально. события -- это "модель изменилась", исключения -- это "команда плохая, модель осталась неизменной". поэтому на события могут подписываться всякие "read models" (т.е. views), а исключения интересны только клиенту. ‎- сосиски супремасиски
ну вот я не уверен, что "команда плохая" не стоит логировать, анализировать и всё остальное, что даёт event sourcing ‎- волна бургерных
вообще идея чистого, строго однонаправленного MVI / MVU кажется мне (теоретически) удобнее. никаких исключений, строго команды и события "состояние изменилось" (в идеале новое состояние есть чистая функция прежнего состояния и команды). но это, конечно, не совсем про разделение "бизнес-логики" и "вторичных технических деталей". с третьей стороны, эти детали часто только кажутся вторичными, а на самом деле для бизнеса могут оказаться важны. ‎- 9000
о, я понял, почему мне не нравится эта система с исключениями - мы сливаем проверку предусловия (которая может кинуть exception) с собственно выполнением команды ради атомарности. но может оно так и лучше, ХЗ, надо пробовать. я писал только очень маленькие и довольно ограниченные реактивные подсистемы, на большое-цельное не хватало ‎- волна бургерных
также у меня появилось подозрение, что Flux uni-directional data flow фактически изоморфен CQRS ‎- волна бургерных