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

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


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


в "хранилище" пока не вся инфа хранится, выходит что по ID далеко не всегда можно поднять. а лишние рест реквесты совсем не хотелось бы плодить, да и ситуация в crm уже может изменится.

да полно там логики, успокойся. а про MDC, ok. не знал. спасибо за наводку.

всем.
сценарии обработки примерно такие - прилетает от crm рест вызов о том, что задача ид 100500 изменилась. далее я идет обработка этой "транзакции". я дергаю рест и получаю детали по задачи, если она связана с заказом, запрашиваю детали заказа, товары привязанные к заказу. тут я могу обнаружить что в моем "хранилище" другой рассклад по позициям, я фиксирую что пришло, что ушло из заказа в "хранилище". т.е. вроде как и вызов был на тему задачи, но у меня уже собраны детальные данные и по заказу и по товарам заказа. и очень вероятно когда я все таки добирусь до обработки самой задачи, то много чего из заказа понадобится, почти наверняка упаковщик заказа.
вобщем наверно действительно нужен тот BaseRequest и туда по мере "открытий" складывать имутабл сущности, с которыми эта "транзакция" сталкивалась по мере обработки. т.е. если понадобились товары из заказа, складывать их BaseRequest и подсовывать весь BaseRequest дальнейшем объектам бизнес логики, например обработчикам задач
да. а результат обработки - какие-то рест реквесты на тему той 100500й задачи. может будет переделан description, добавятся комментарии, может та задача будет переназначена на другого менеджера.

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



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

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


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