Bagaimana cara menentukan apakah suatu pesan harus berupa pesan perintah atau pesan acara?

Dua pola integrasi perusahaan adalah pesan perintah dan pesan acara . Saya sedang mengerjakan suatu sistem di mana kami menggunakan pesan tidak hanya untuk integrasi dengan sistem lain, tetapi untuk komunikasi internal antar layanan. Ini seharusnya menjadi sistem yang akhirnya konsisten , dan layanan seharusnya saling mengabaikan (dengan pengecualian untuk beberapa layanan tujuan khusus). Karena itu, kami mencoba menghindari hal-hal yang terasa seperti panggilan prosedur jarak jauh (RPC atau RPI). Kami memiliki sistem middleware bus dan berorientasi pesan, dan semua pesan disiarkan.

Kita cenderung menyebut pesan kita sebagai peristiwa, yaitu, sebagai frase di masa lalu yang sempurna, misalnya PurchaseOrderShipped. Namun, acara sering ditambahkan hanya ketika beberapa layanan lain perlu tahu tentang mereka, dan pada awalnya, seringkali hanya satu layanan yang peduli. Selain itu, kadang-kadang layanan itu memancarkan suatu peristiwa, yang didengarkan oleh layanan pertama. Jadi jika saya membuat diagram interaksi, itu akan terlihat lebih seperti diagram untuk pesan perintah di tautan di atas (atau bahkan diagram RPC) daripada yang untuk pesan acara, meskipun sekali lagi, ini tidak benar-benar diterapkan dengan pesan langsung tetapi disiarkan di bus. Tambahkan ke fakta bahwa saya baru saja melihat beberapa pesan yang ditambahkan yang dinamai perintah, yaitu, frase dalam imperatif, misalnya BillShippedPurchaseOrder.

Yang aneh adalah bahwa nama-nama pesan dan cara mereka mengalir tidak berubah oleh apakah itu disebut sebagai suatu peristiwa atau sebagai perintah. Jadi bagaimana seseorang menentukan apakah sesuatu harus berupa pesan perintah atau peristiwa? Apakah ini hanya perbedaan semantik dan penamaan, atau adakah perbedaan implementasi yang sebenarnya antara pesan perintah dan acara? Mengingat bahwa semua pesan kami disiarkan, apakah itu berarti daripada tidak satupun dari mereka yang benar-benar pesan perintah?

Ada perbedaan kecil namun penting antara perintah dan acara. Sebuah perintah memiliki anggapan tentang respons sedangkan suatu peristiwa tidak menganggap tanggapan, itu hanya sebuah pernyataan.

Menjadi kurang abstrak:

ShipOrderadalah perintah dan pengirim ShipOrderkemungkinan akan mengharapkan respons.
OrderShippedadalah deklarasi dan pengirim tidak mungkin mengharapkan respons seperti respons GoodJob!yang tidak berguna dalam contoh ini.

Jika Anda merancang sistem Anda hanya untuk mengharapkan pesan acara, maka tidak perlu bagi sistem untuk mendesain apa yang Anda sebut pesan. Pengembang mungkin bingung dengan nama pesan, tetapi sistem akan merespons dengan baik terlepas dari konvensi apa yang Anda ikuti untuk menyebutkan beberapa hal.

Tapi itu tidak terdengar seperti rekan pengembang Anda mengikuti model pesan hanya acara. Jika layanan mengharapkan tanggapan terhadap "pesan acara" yang mereka kirimkan, maka mereka benar-benar mengirimkan pesan perintah. Ini bukan masalah besar, dan saya bisa memikirkan banyak kasus di mana perintah seperti permintaan informasi akan diperlukan. Tetapi Anda akan mengalami sakit kepala semantik jika Anda diharapkan hanya melihat pesan acara.

Pesan siaran tidak benar-benar berdampak pada apakah pesan itu perintah atau peristiwa. Secara umum, Anda tidak menyiarkan perintah karena menduplikasi usaha. Tapi tidak ada yang bisa dikatakan kamu tidak bisa. Protokol jaringan awal menyiarkan setiap paket dan penerima harus cukup pintar untuk tahu kapan harus mengabaikanpesan paket yang bukan milik mereka.

Pesan acara adalah sesuatu yang baru saja terjadi. Anda memberi tahu acara yang baru saja terjadi.

Pesan Perintah adalah pesan yang mengharapkan sesuatu untuk dilakukan. Mungkin atau mungkin tidak mengharapkan tanggapan.

Kapan harus menggunakan apa yang datang ke kopling dan perbedaannya hanya akan muncul seiring waktu ketika sistem berevolusi. Acara yang disukai daripada perintah menghasilkan lebih sedikit sambungan. Emitor dari acara tersebut tidak peduli dengan konsumen. Dalam pola perintah pemanggil tahu dan karenanya tergantung pada keberadaan penyedia.

Bill Poole menyarankan menghindari pesan perintah secara bersamaan: http://bill-poole.blogspot.com.au/2008/04/avoid-command-messages.html

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