Больше никаких

Ну т.е. я буду городить всю портянку es ради истории операций? Ради призрачной надежды когда-либо откатить состояние агрегата? Вы шутите?

Какую портянку?

всю реализацию

весь оверхед

Какую реализацию, реализацию хранения ивентов?

Какой оверхед, с чем мы сравниваем?

реализацию хранения эвентов, их применения, генерации представлений на основе оных. Для чего мне всё это в рамках простой задачи, которая решается с помощью 2-3х таблиц в тёплом ламповом mysql? Я с пониманием, что es/cqrs нынче модная и хайповая схема, но на кой чёрт её тянуть во все щели? зачем пытаться микроскопом гвозди забивать? (да, он тоже для этого подходит, но это не значит, что он будет хорошим выбором).

реализацию хранения эвентов, их применения, генерации представлений на основе оных. Для чего мне всё это в рамках простой задачи, которая решается с помощью 2-3х таблиц в тёплом ламповом mysql? Я с пониманием, что es/cqrs нынче модная и хайповая схема, но на кой чёрт её тянуть во все щели? зачем пытаться микроскопом гвозди забивать? (да, он тоже для этого подходит, но это не значит, что он будет хорошим выбором).

Реализация хранения ивентов проще реализации хранения целого стейта, генерацию вьюх можно не делать, запихайте гетерый в write model

И у вас остаются 2-3 таблицы

Реализация хранения ивентов проще реализации хранения целого стейта, генерацию вьюх можно не делать, запихайте гетерый в write model

Часто проще, в любом случае всегда можно жсоны хранить и не париться изначально про схему и страшные миграции

Особенно когда идут операции с деньгами, лучше иметь историю и в случае чего посмотреть, где что-то пошло не так, чем смотреть на состояние счета и говорить, ну хз у нас записано 40 баксов на счете)

в случае работы через агрегатора это не нужно от слова совсем

задача клиентского кода - сформировать запрос и средиректить пользователя. Затем получить его назад вместе с флагом "ок/не ок"

всё, что касается денег, систему не касается в принципе.

Так зачем тогда билинг?)

цены редактировать, премиум аккаунты выдавать)

И вообще какие-то таблицы, если все не у вас

Задача решается без таблиц вообще)

почитайте там описание, которое парень скидывал) там задача на 3-4 файлика. А тут накинулись защитники православного cqrs/es

и, да, восстанавливать состояние стейтов за 5 лет работы в агрегаторе платежей мне пришлось ровно 1 раз: когда одмин базу переломал со своими переключениями мастеров. Но если бы он такой номер провернул с базой событий, попу бы всем раздраконили под 0.

Почему-то никто не спросил, есть ли у команды, которая будет реализовывать функциональность, опыт построения систем (хотя бы на уровне личных проектов) на cqrs и es :) Опыта нет, а это, по-моему, железный аргумент против применения той или иной технологии или подхода в продакшене.

С точки зрения идеи там довольно просто всё. Реализации бывают разной степени замудрённости. И только

Приветствую всех

реализацию хранения эвентов, их применения, генерации представлений на основе оных. Для чего мне всё это в рамках простой задачи, которая решается с помощью 2-3х таблиц в тёплом ламповом mysql? Я с пониманием, что es/cqrs нынче модная и хайповая схема, но на кой чёрт её тянуть во все щели? зачем пытаться микроскопом гвозди забивать? (да, он тоже для этого подходит, но это не значит, что он будет хорошим выбором).

пойдем от обратного. В ситуации с mysql у тебя будет теплая ламповая табличка с транзакциями которая хранит операции, и ты будешь делать sql запросы + кэш который будет являсться своего рода проекцией.

или по другому, если нам нужно процессить инвойсы, у тебя будут мутабельные инвойсы, статус оплачен или ожидает оплаты например

и на основе оного будет приниматься решение что кому и т.д.

нет?

почитайте там описание, которое парень скидывал) там задача на 3-4 файлика. А тут накинулись защитники православного cqrs/es

сча почитаю

по факту у нас есть: - покупка внутреигровой валюты - проведение транзакций используя внутреигровые валюты - покупка премиум аккаунтов

правильно понимаю?

Ну опять-таки есть множество разных вариаций. Например, не редки кейсы, когда 1 инвойс (счёт фактуру, если угодно) можно оплачивать с помощью нескольких сервис-провайдеров. Но в нашем случае кол-во логики минимально. Собрали форму, отсабмитили, получили нотификацию и выдали аккаунт. Усё

Ну опять-таки есть множество разных вариаций. Например, не редки кейсы, когда 1 инвойс (счёт фактуру, если угодно) можно оплачивать с помощью нескольких сервис-провайдеров. Но в нашем случае кол-во логики минимально. Собрали форму, отсабмитили, получили нотификацию и выдали аккаунт. Усё

как количество сервис провайдеров влияет на реализацию?

Очень сильнл

Усложняет логику в миллионы раз

это влияет только на процедуру проведения/верификации платежа, инвойсы ж плевать

не совсем так

Усложняет логику в миллионы раз

я плохо видимо понимаю. Ты про "ну вот можно через страйп, можно через биткойны какие"... такие сервис провайдеры?

скорее: половину через страйп, а половину счёта через биткоины

скорее: половину через страйп, а половину счёта через биткоины

ммм... разделение транзакции типа и при этом что бы она атомарной оставалась?)

там начинается свистопляска с суммой транзакций по инвойсу, к их возврату в случае чего (и сторнирование следом). Куча бизнесовых правил под всякую отчётную дрянь. вот тут как раз ес в цвет залетит

окей, а если у нас тупо робокасса (пока что, хз что будет завтра) - ES не взлетает потому что "сложно"?)

оверхэд в чем?

всё же давай от обратного: профит в чём?

или ты про факт отсутствия вменяемых и удобных реализаций готовой инфраструктуры для cqrs/es?

всё же давай от обратного: профит в чём?

как минимум отчетность, как максимум проще управлять всем этим делом

проще логику скейлить

я сам в состоянии написать и более того, уже это сделал. я не против es/cqrs, я против советов оного варианта человеком, который не особо в курсе специфики работы агрегаторов

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

отчётность робокассы получается за 2 минуты в личном кабинете

я сам в состоянии написать и более того, уже это сделал. я не против es/cqrs, я против советов оного варианта человеком, который не особо в курсе специфики работы агрегаторов

расскажи про оверхэд подробнее, как ты его видишь?

для начала мне нужно написать реализацию cqrs (предположим, что у меня её нет и я на распутье). Это первый и ключевой момент. второй момент - мне никто так и не смог объяснить, за каким хреном мне в принципе писать эту реализацию, если весь геморрой лежит на стороне агрегатора, а мне надо только сматчить айдишник оплаченного ордера с айдишником платежа

для начала мне нужно написать реализацию cqrs (предположим, что у меня её нет и я на распутье). Это первый и ключевой момент. второй момент - мне никто так и не смог объяснить, за каким хреном мне в принципе писать эту реализацию, если весь геморрой лежит на стороне агрегатора, а мне надо только сматчить айдишник оплаченного ордера с айдишником платежа

что есть "реализация cqrs" в твоем понимании?

es за слеш ещё добавь. cqrs как таковой делать не надо

> а мне надо только сматчить айдишник оплаченного ордера с айдишником платежа предположим что у нас все еще на нашей стороне остались платежи во внутреигровой валюте

es за слеш ещё добавь. cqrs как таковой делать не надо

- сделать штуки которые генерят ивенты - сделать так что бы можно было зааплаить ивент на сущность - заюзать любой готовый event store

если мы возьмем к примеру php, и тамошние штуки типа доктрины - как по мне уже тянет на больше дел (надо разобраться как работает доктрина. учитывать ограничения которые оно накладывает)

платежи во внутреигровой валюте нас в принципе никак не касаются в вопросах биллинга. Это простой апдейт 2 записей в 1 таблице в рамках 1 транзакции. Лог записать, если сильно хочется

транзакция - в контексте субд

платежи во внутреигровой валюте нас в принципе никак не касаются в вопросах биллинга. Это простой апдейт 2 записей в 1 таблице в рамках 1 транзакции. Лог записать, если сильно хочется

то есть у нас есть тупо аккаунты и их балансы

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

лог можешь вести, если сильно поджимает параноя

логирование есть по определению +/- в любом приложении. Делать лишнего не нужно.

а еще можно взять готовый лэджер

Если я не ошибаюсь, ты громче всех тут хайпишь за ноду, тайпскрипт, ангуляр, микросервисы и прочий "важный и нужный" стек

Если я не ошибаюсь, ты громче всех тут хайпишь за ноду, тайпскрипт, ангуляр, микросервисы и прочий "важный и нужный" стек

ошибаешься)

есть те, кто громче?)

но чем всё это хуже втиснуть es/cqrs в любую дырку - вопрос риторический.

человек попросил биллинг - es ложится на биллинг очень хорошо. Потом оказалось что весь процессинг платежей будет делаться готовой штукой. Приходим к тому что ты предложил.

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

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

частично можно использовать для отчётности, как ранее писал, но не более. К самому процессингу - неа

частично можно использовать для отчётности, как ранее писал, но не более. К самому процессингу - неа

по че му

пока я слышу только "сложна", "нет профита"

причем альтернативы ты не приводишь

с чем сравниваешь

знаешь почему?

твоё представление о прохождении платежа очень похоже на проведение банковской транзакции. Прям как по учебнику. Списали с 1 счёта, зачислили на другой, записали отчётик.

возьми ради интереса схему прохождения платежа у visa/mastercard. Накинь на es/cqrs

а что б совсем хорошор было: схема платежа = снятие наличных по карте visa в банкомате чужого банка. Вот где раздолье

Если я не ошибаюсь, ты громче всех тут хайпишь за ноду, тайпскрипт, ангуляр, микросервисы и прочий "важный и нужный" стек

ну вот сам выдумал и других обвиняешь)

возьми ради интереса схему прохождения платежа у visa/mastercard. Накинь на es/cqrs

там сложность инфраструктурная, она одинаковая вне зависимости от того es у тебя или что-то другое(просто стейт?)

там сложность инфраструктурная, она одинаковая вне зависимости от того es у тебя или что-то другое(просто стейт?)

инфраструктурой и требованиями pci-dss можно принебречь.

но процесс я сейчас посмотрю детальнее)

инфраструктурой и требованиями pci-dss можно принебречь.

тогда и сложности не вижу)

у тебя есть действующие протоколы проведения транзакций, нет?

действующие протоколы?

ну не протоколы, короч всякие там CIPS и т.д.

На такой уровень cips/swift шпану не пускают

так что нет, нету. Ни один агрегатор доступа к ним никогда не получит)

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

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

но мы же не учитываем сейчас в этом сферическом в вакууме кейсе реалии страны?)

раз уж ты по инфраструктуре ограничения убрал

если брать в рассчёт межбанковское взаимодействие, то там не совсем транзакции в привычном понимании. если сильно упрощенно, то это больше похоже на обмен векселями

если брать в рассчёт межбанковское взаимодействие, то там не совсем транзакции в привычном понимании. если сильно упрощенно, то это больше похоже на обмен векселями

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

у меня опыт есть только с гейтвеями