hVosttskyANAЧто я конкретно имею в виду: первая система (касса) выполняет списание бонусов и факт этого списания заносит в свою табличку, или коллекцию, или файл, или...

Я думаю там в любом случае операции с бонусами как-то фиксируются. Незачем заводить ещё одну какую-то табличку, коллекцию или файл.

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

А если операция не удалась и в табличку ничего не записано. Пусть сервисы ждут у моря погоды? Или выжидают время и считают, что всё — каюк? Хрень какая-то.
Если операция не удалась, то не удалась. А сервисы ничего в моей схеме не ждут. :)

hVosttskyANAЕсли операция не удалась, то не удалась. А сервисы ничего в моей схеме не ждут. :)

Поэтому и не применимо к задачам ТС
Не понимаю почему. Хотелось бы увидеть объяснение.

hVosttskyANAНе понимаю почему. Хотелось бы увидеть объяснение

Потому что нет конкретного и однозначного ответа на вопрос: выполнилось действие или нет, и с каким результатом. Всё, что есть: это какая-то рассылка брокером фактов списаний бонусов.
Как нет, есть в первой системе. Факт списания бонусов - это и есть выполненное действие.

hVosttskyANAКак нет, есть в первой системе. Факт списания бонусов - это и есть выполненное действие.

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

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

По мне времена взаимодейтсивя клиент сервер давно уже прошли, наступило время распределённой архитектуры.

Пояснения к картинке:
ИП - интерфейс пользователя

ЛП - логика приложения

ДД - доступ к данным

БД - база данных

hVosttskyANAТак в чём проблема-то? Зачем во второй системе, в CRM фиксировать действия из первой системы?

Потому что:

А) там может сидеть юзер и ожидать реакции системы, не важно какой
Б) сама система может принимать совершенно разные и удивительные решения на основе результата выполнения операции внешней системы
В) на основе операций может генерироваться множество других изменений в данных и артефактов, кроме непосредственно факта списания бонусов
Г) система на основе действий расширяема, без ковыряния левых брокеров, систем рассылки, ведения буферов и таблиц, от которых зависит всё, точка соприкасания систем фокусируется исключительно на действиях, что снижает связанность


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

Слишком широко. Клиенту важно получить результат выполненной операции, если он её инициировал. Я подозреваю, что некий журнал операций всё равно будет. Но про доставку это «записи», я уже говорил. Это один из кейсов: клиент говорит сервису, куда ему доставить результат и отрубается. Подписка на событие. Зачем клиенту получать вообще все записи из журнала, не ясно.


skyANAПо мне времена взаимодейтсивя клиент сервер давно уже прошли, наступило время распределённой архитектуры

Ну вот. Помнишь ты спрашивал про модные техники? Сам же и сказал
Всё что ты тут понаписал, никак не противоречит моей идее.

hVosttСлишком широко. Клиенту важно получить результат выполненной операции, если он её инициировал. Я подозреваю, что некий журнал операций всё равно будет. Но про доставку это «записи», я уже говорил. Это один из кейсов: клиент говорит сервису, куда ему доставить результат и отрубается. Подписка на событие. Зачем клиенту получать вообще все записи из журнала, не ясно.
Тут под клиентом я имел ввиду человека, что пришёл и купил что-то за бонусы. А в конце месяца сидит дома и смотрит в личном кабинете выписку по операциям за месяц.

hVostt, и кстати раскрой что такое "система на основе действий". Для меня это попахивает управленческим учётом и бизнес-аналитикой и лежит мягко говоря в другой плоскости, чем проблема ТСа.

hVosttskyANAТут под клиентом я имел ввиду человека, что пришёл и купил что-то за бонусы. А в конце месяца сидит дома и смотрит в личном кабинете выписку по операциям за месяц.

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

hVosttskyANAhVostt, и кстати раскрой что такое "система на основе действий". Для меня это попахивает управленческим учётом и бизнес-аналитикой и лежит мягко говоря в другой плоскости, чем проблема ТСа.

Система на основе действий, это грубо говоря любой вызов функции и получение результата. В бизнесе, это это можно назвать бизнес-транзакцией. Приплетать сюда какую-то конкретную предметную область вовсе не обязательно.Хм... Ты таки об Activity-Based Information System (ABIS) или нет?