Чем идентификатор команды отличается от идентификатора сообщения инфраструктуры?

Question

Я думаю о чем-то, что немного связано с CQRS.Есть шаблон запроса-ответа.В примере HTTP-транспорта в заголовок мы помещаем Request-Id как минимум для отслеживания.В моем случае мониторинг между разными микросервисами.Если входящий запрос содержит его, то выполняется перезапись заголовка Correlation-Id .Как мне кажется, это делается на транспортном уровне (инфраструктура).Вопрос в том, должен ли этот Request-Id (иногда называемый Message-Id) доставляться из бизнес-уровня, например, непосредственно из команды, которую мы выполняем - некоторые механизмы делают это автоматически - как ICommand требует наличия Id?Или это совершенно другая вещь, которая существует только на уровне инфраструктуры (транспорт)?Если да, то как соотнести идентификатор транспорта с идентификатором бизнес-команды?По крайней мере, одна вещь журнала / трассировки / трека должна быть размещена с обоими идентификаторами?Есть ли pattenr, который я пропустил?Кроме того, какой, по вашему мнению, CorrelationId должен быть в деловой команде или нет?

Answer 1

ИМХО такие понятия, как идентификатор корреляции, идентификатор причины, идентификатор запроса, идентификатор сообщения и т. Д., Относятся к уровню инфраструктуры, поскольку они не являются частью бизнес-правил.

Однако я добавил * 1003Атрибут * metadata для моих объектов Command и Event для сохранения такого рода информации, которая помогает мне управлять корреляцией и причинно-следственными связями между командами и событиями.

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