Як визначити, чи повинно бути повідомлення командного чи події?

Два схеми інтеграції підприємства - це командне повідомлення та повідомлення про подію . Я працюю над системою, в якій ми використовуємо обмін повідомленнями не тільки для інтеграції з іншими системами, але і для внутрішнього спілкування між службами. Це повинна бути врешті-решт послідовна система, і служби повинні не знати один одного (за винятком декількох служб спеціального призначення). Таким чином, ми намагаємось уникати речей, які мають вигляд віддалених процедурних дзвінків (RPC або RPI). У нас є система проміжного програмного забезпечення, орієнтована на шину та повідомлення, і всі повідомлення транслюються.

Ми схильні називати наші повідомлення як події, тобто як фразу в минулому досконалому, наприклад PurchaseOrderShipped. Однак події часто додаються лише тоді, коли деякі інші сервіси повинні знати про них, і на початку часто стосується лише однієї послуги. Більше того, іноді ця послуга в результаті випробовує подію, яку слухає перша служба. Таким чином, якби я планував взаємодію, це було б набагато більше схоже на діаграму командного повідомлення у посиланні вище (або навіть на схему RPC), ніж на повідомлення про подію, хоча, ще раз, це насправді не реалізовано з прямі повідомлення, але транслюються в автобусі. Додайте до цього той факт, що я нещодавно бачив, як додаються деякі повідомлення, названі як команди, тобто фраза в імперативі, наприклад BillShippedPurchaseOrder.

Дивна річ у тому, що назви повідомлень та спосіб їх перебігу не змінюються незалежно від того, називаються вони як подія чи як команда. Тож як можна визначити, чи повинно щось бути командним повідомленням чи подією? Це лише різниця семантики та імен, чи є фактична різниця в реалізації між повідомленнями команд та подій? Зважаючи на те, що всі наші повідомлення транслюються, чи означає це, що жодне з них є справді командними повідомленнями?

— Казарк
джерело

Відповіді:

Існує тонка, але важлива різниця між командами та подіями. Команда має презумпцію відповіді, тоді як подія не передбачає відповіді, це лише твердження.

Щоб бути менш абстрактним:

ShipOrderце команда, і відправник ShipOrder, ймовірно, очікує певної відповіді.
OrderShippedє декларацією, і відправник навряд чи очікує відповіді, оскільки GoodJob!це марна відповідь у цьому прикладі.

Якщо ви проектуєте ваші системи очікувати лише повідомлень про події, тоді не обов'язково має значення для дизайну системи те, як ви називаєте повідомлення. Розробники можуть заплутатися у назві повідомлення, але системи реагуватимуть чудово, незалежно від того, до якої конвенції ви дотримуєтесь, щоб називати речі.

Але це не здається, що ваші колеги-розробники дотримуються моделі повідомлення лише про події. Якщо служби очікують відповідей на "повідомлення про події", які вони надсилають, то вони дійсно надсилають командні повідомлення. Це не велика справа, і я можу придумати багато випадків, коли потрібні такі команди, як запити інформації. Але у вас буде семантичний головний біль, якщо ви розраховували бачити лише повідомлення про події.

Трансляція повідомлень насправді не впливає на те, чи є повідомлення командою чи подією. Як правило, ви не транслюєте команди, оскільки це дублює зусилля. Але нічого сказати, що ти не зміг. Ранні мережеві протоколи транслювали кожен пакет, і приймачі повинні були бути досить розумними, щоб знати, коли їх ігнорувати~~повідомлення~~ пакети, які не належали їм.

Як ви реалізуєте request for informationфункціональні можливості? Здається, природно використовувати щось на зразок, getUserInfo(uid)яке є командним повідомленням, яке очікує відповіді. Я знаю, що командні повідомлення вводять з'єднання, але, на жаль, у цьому випадку я не бачу, як це реалізувати з повідомленнями про події. Або просто добре дотримуватися командних повідомлень у таких випадках, як це?

— du369

@ du369 Вибачте, але я не зовсім відповідаю за вашим запитанням. Здається, ви намагаєтеся створити команду, але використовуєте події?

Так, майже це. У посиланні, наведеному у відповіді Лі, однаковий функціонал реалізований двома різними способами. Один використовує CancelPolicyRequestповідомлення, яке є командою. Інший підхід використовує два повідомлення про події, а саме InvoicePastDueNotificationта PolicyCancelledNotification. Тож мені цікаво, чи можна змінювати команди типу getUserInfo(uid)стилю повідомлень про події і як мені це робити?

— du369

@ du369 Щось, десь треба виконати Actionпов'язане з командою. З командою є два етапи. 1) чи потрібна команда (наприклад, політика закінчилася), і 2) виконати команду (наприклад, скасувати політику). Якщо Actorце визначає, чи потрібна команда AND може виконати, то Actorце може відправити повідомлення про події. В іншому випадку все, що визначає, що команда потрібна, потрібно надіслати подію команди.

Повідомлення про подію - це те, що щойно відбулося. Ви повідомляєте про щойно відбулася подія.

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

Коли використовувати те, що зводиться до з’єднання, і різниця з’явиться лише з часом, коли системи розвиватимуться. Уподобання подій над командами призводить до меншої зв'язку. Емітер події не піклується про споживача. У командному шаблоні абонент знає і тому залежить від існування постачальника.

Білл Пул пропонує уникати командних повідомлень разом: http://bill-poole.blogspot.com.au/2008/04/avoid-command-messages.html

http://bill-poole.blogspot.com.au/

— Лі Сімпсон
джерело

Лі, дякую за вашу відповідь, але я розумію теорію, що стоїть за визначенням кожного. Моє запитання - як це застосувати в реальному житті --- коли сповістити, що щось сталося, що часто призводить до того, що щось робиться, і коли вимагати, щоб щось було зроблено.

— Казарк

Я думаю, що це зводиться до зв'язку, і різниця з’явиться лише з часом, коли системи розвиватимуться. Уподобання подій над командами призводить до меншої зв'язку. Емітер події не піклується про споживача. У командному шаблоні абонент знає і тому залежить від існування постачальника. Ви читали статті Білла Пула?

— Лі Сімпсон

Лі, дякую, це корисно; насправді, я пропоную вам відредагувати вміст свого коментаря у свою відповідь, включаючи посилання на статті Пула (про що я не впевнений, що читав).

— Казарк