Làm thế nào để xác định xem một tin nhắn nên là một tin nhắn lệnh hay tin nhắn sự kiện?


11

Hai mẫu tích hợp doanh nghiệp là thông điệp lệnhthông báo sự kiện . Tôi đang làm việc trên một hệ thống trong đó chúng tôi sử dụng nhắn tin không chỉ để tích hợp với các hệ thống khác mà còn cho giao tiếp nội bộ giữa các dịch vụ. Nó được coi là một hệ thống nhất quán cuối cùng và các dịch vụ được coi là không biết gì về nhau (ngoại trừ một vài dịch vụ có mục đích đặc biệt). Vì vậy, chúng tôi cố gắng tránh những thứ cảm thấy như các cuộc gọi thủ tục từ xa (RPC hoặc RPI). Chúng tôi có một hệ thống phần mềm trung gian hướng xe buýt và tin nhắn, và tất cả các tin nhắn được phát sóng.

Chúng ta có xu hướng đặt tên tin nhắn của mình là sự kiện, nghĩa là, như một cụm từ trong quá khứ hoàn hảo, vd PurchaseOrderShipped. Tuy nhiên, các sự kiện thường chỉ được thêm vào khi một số dịch vụ khác cần biết về chúng và ban đầu, thường chỉ có một dịch vụ quan tâm. Hơn nữa, đôi khi dịch vụ đó phát ra một sự kiện do đó được lắng nghe bởi dịch vụ đầu tiên. Do đó, nếu tôi lập sơ đồ tương tác, nó sẽ trông giống như sơ đồ cho thông báo lệnh trong liên kết ở trên (hoặc thậm chí là sơ đồ RPC) so với sơ đồ cho thông báo sự kiện, mặc dù một lần nữa, điều này thực sự không được thực hiện với nhắn tin trực tiếp nhưng phát trên xe buýt. Thêm vào đó là thực tế gần đây tôi đã thấy một số tin nhắn được thêm vào được đặt tên là các lệnh, nghĩa là một cụm từ trong mệnh lệnh, ví dụ BillShippedPurchaseOrder.

Điều kỳ lạ là tên của các thông điệp và cách chúng truyền tải không thay đổi bằng việc nó được đặt tên là một sự kiện hay là một lệnh. Vậy làm thế nào để xác định xem một cái gì đó nên là một thông điệp lệnh hay một sự kiện? Đây chỉ là một sự khác biệt về ngữ nghĩa và đặt tên, hay có sự khác biệt thực hiện thực tế giữa các thông báo lệnh và sự kiện? Cho rằng tất cả các tin nhắn của chúng tôi được phát sóng, điều đó có nghĩa là không ai trong số chúng là tin nhắn thực sự?

Câu trả lời:


11

Có một sự khác biệt tinh tế, nhưng quan trọng giữa các lệnh và sự kiện. Một lệnh có một giả định của một phản hồi trong khi một sự kiện không giả định một phản hồi, đó chỉ là một tuyên bố.

Để ít trừu tượng hơn:

ShipOrderlà một lệnh và người gửi ShipOrdersẽ có khả năng mong đợi một phản hồi nào đó.
OrderShippedlà một tuyên bố và người gửi không thể mong đợi một phản hồi cũng như GoodJob!một phản hồi vô ích trong ví dụ này.

Nếu bạn đang thiết kế hệ thống của mình chỉ mong đợi thông báo sự kiện, thì điều đó không nhất thiết đối với thiết kế hệ thống mà bạn gọi là thông báo. Các nhà phát triển có thể bị nhầm lẫn bởi tên của một thông điệp, nhưng các hệ thống sẽ phản hồi tốt bất kể bạn tuân theo quy ước nào để đặt tên cho mọi thứ.

Nhưng có vẻ như các nhà phát triển đồng nghiệp của bạn đang theo mô hình thông báo chỉ dành cho sự kiện. Nếu các dịch vụ đang mong đợi phản hồi cho "thông báo sự kiện" mà chúng đang gửi, thì chúng thực sự đang gửi tin nhắn lệnh. Đó không phải là một vấn đề lớn và tôi có thể nghĩ ra nhiều trường hợp các lệnh như yêu cầu thông tin sẽ được yêu cầu. Nhưng bạn sẽ bị đau đầu về ngữ nghĩa nếu bạn chỉ muốn xem các thông báo sự kiện.

Tin nhắn quảng bá không thực sự có tác động đến việc tin nhắn là lệnh hay sự kiện. Nói chung, bạn không phát các lệnh vì nó nhân đôi nỗ lực. Nhưng không có gì để nói bạn không thể. Các giao thức mạng ban đầu phát sóng mọi gói và người nhận phải đủ thông minh để biết khi nào nên bỏ quatin nhắn các gói không thuộc về họ.


Làm thế nào để bạn thực hiện các request for informationchức năng? Có vẻ tự nhiên khi sử dụng một cái gì đó giống như getUserInfo(uid)một thông điệp lệnh tạo ra phản hồi. Tôi biết rằng các thông báo lệnh giới thiệu khớp nối, nhưng thật đáng buồn trong trường hợp này, tôi không thấy cách triển khai nó với các thông báo sự kiện. Hoặc nó chỉ là tốt để dính vào tin nhắn lệnh trong một số dịp như thế này?
du369

@ du369 Xin lỗi, nhưng tôi không hoàn toàn làm theo câu hỏi của bạn. Nghe có vẻ như bạn đang cố gắng tạo một lệnh nhưng sử dụng các sự kiện?

Vâng, khá nhiều đó. Trong liên kết được cung cấp trong câu trả lời của Lee, chức năng tương tự được triển khai theo hai cách khác nhau. Một là sử dụng CancelPolicyRequesttin nhắn là một lệnh. Cách tiếp cận khác sử dụng hai thông điệp sự kiện, cụ thể là InvoicePastDueNotificationPolicyCancelledNotification. Vì vậy, tôi tự hỏi nếu có thể trò chuyện các lệnh như getUserInfo(uid)phong cách thông báo sự kiện và làm thế nào tôi có thể làm điều đó.
du369

1
@ du369 Một cái gì đó, một nơi nào đó phải thực hiện Actionliên kết với lệnh. Có hai bước liên quan đến một lệnh. 1) Là lệnh cần thiết (ví dụ: chính sách đã hết hạn) và 2) thực thi lệnh (ví dụ: hủy bỏ chính sách). Nếu Actorđiều đó xác định nếu lệnh là cần thiết VÀ có thể thực thi, thì đó Actorcó thể gửi thông điệp sự kiện. Mặt khác, bất cứ điều gì xác định rằng lệnh là cần thiết để gửi một sự kiện lệnh.

5

Một thông báo sự kiện là một cái gì đó vừa xảy ra. Bạn đang thông báo về sự kiện vừa xảy ra.

Thông báo lệnh là một thông điệp mong muốn một cái gì đó được thực hiện. Nó có thể hoặc không thể mong đợi một phản ứng.

Khi sử dụng những gì đi xuống để khớp nối và sự khác biệt sẽ chỉ xuất hiện theo thời gian khi các hệ thống phát triển. Sự kiện ưa thích trên các lệnh dẫn đến kết nối ít hơn. Người phát ra sự kiện không quan tâm đến người tiêu dùng. Trong một mẫu lệnh, người gọi biết và do đó phụ thuộc vào sự tồn tại của nhà cung cấp.

Bill Poole đề nghị tránh tất cả các thông điệp lệnh: http://bill-poole.blogspot.com.au/2008/04/avoid-command-messages.html

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


Lee, cảm ơn câu trả lời của bạn, nhưng tôi hiểu lý thuyết đằng sau định nghĩa của mỗi. Câu hỏi của tôi là làm thế nào để áp dụng điều này trong cuộc sống thực --- khi nào cần thông báo rằng điều gì đó đã xảy ra, điều này thường dẫn đến việc gì đó được thực hiện và khi nào yêu cầu điều gì đó được thực hiện.
Kazark 7/1/2015

Tôi nghĩ rằng nó đi xuống khớp nối và sự khác biệt sẽ chỉ xuất hiện theo thời gian khi các hệ thống phát triển. Sự kiện ưa thích trên các lệnh dẫn đến kết nối ít hơn. Người phát ra sự kiện không quan tâm đến người tiêu dùng. Trong một mẫu lệnh người gọi biết và do đó phụ thuộc vào sự tồn tại của nhà cung cấp. Bạn đã đọc các bài viết của Bill Poole?
Lee Simpson

Lee, cảm ơn, điều đó hữu ích; thực tế, tôi khuyên bạn nên chỉnh sửa nội dung từ bình luận của bạn thành câu trả lời của bạn, bao gồm một liên kết đến các bài viết của Poole (mà tôi không chắc là tôi đã đọc).
Kazark
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.