Tại sao các lệnh và sự kiện được biểu diễn riêng biệt?

Sự khác biệt giữa lệnh và sự kiện trong kiến ​​trúc nhấn mạnh sự kiện là gì? Điểm khác biệt duy nhất mà tôi có thể thấy là các lệnh thường được lấy / gọi bởi các tác nhân bên ngoài hệ thống, trong khi các sự kiện dường như được lấy từ các trình xử lý và mã khác trong hệ thống. Tuy nhiên, trong nhiều ứng dụng ví dụ mà tôi đã thấy, chúng có giao diện khác nhau (nhưng giống nhau về chức năng).

Các lệnh có thể bị từ chối.

Sự kiện đã xảy ra.

Đây có lẽ là lý do quan trọng nhất. Trong kiến ​​trúc hướng sự kiện, không thể nghi ngờ rằng một sự kiện được nêu ra đại diện cho một điều gì đó đã xảy ra .

Bây giờ, vì Lệnh là thứ chúng ta muốn xảy ra và Sự kiện là thứ đã xảy ra, chúng ta nên sử dụng các động từ khác nhau khi đặt tên cho những thứ này. Điều này thúc đẩy các đại diện riêng biệt.

Tôi có thể thấy rằng các lệnh thường được lấy / gọi bởi các tác nhân bên ngoài hệ thống, trong khi các sự kiện dường như được lấy từ các trình xử lý và mã khác trong hệ thống

Đây là một lý do khác khiến chúng được đại diện riêng biệt. Khái niệm rõ ràng.

Lệnh và Sự kiện đều là Thông báo. Nhưng thực tế chúng là những khái niệm riêng biệt và các khái niệm nên được mô hình hóa một cách rõ ràng.

Ngoài ra, ngoài tất cả các câu trả lời ở đây được hiển thị, một trình xử lý sự kiện cũng có thể kích hoạt một lệnh sau khi nhận được thông báo rằng một sự kiện đã xảy ra.

Ví dụ: giả sử sau khi bạn tạo Khách hàng, bạn cũng muốn khởi tạo một số giá trị tài khoản, v.v. Sau khi Khách hàng AR của bạn thêm sự kiện vào EventDispatcher và điều này được đối tượng CustomerCreateEventHandler nhận được, trình xử lý này có thể kích hoạt gửi một lệnh. sẽ thực thi bất cứ điều gì bạn cần, v.v.

Ngoài ra, còn có DomainEvents và ApplicationEvents. Sự khác biệt chỉ đơn giản là khái niệm. Bạn muốn gửi tất cả các sự kiện miền của mình trước (một số trong số chúng có thể tạo ra Sự kiện ứng dụng). Ý tôi là gì?

Việc khởi tạo tài khoản sau khi CustomerCreateEvent đã xảy ra là một sự kiện DOMAIN. Gửi thông báo qua email cho Khách hàng là một Sự kiện Ứng dụng.

Lý do bạn không nên trộn chúng đã rõ ràng. Nếu máy chủ SMTP của bạn tạm thời ngừng hoạt động, điều đó không có nghĩa là HOẠT ĐỘNG TRONG MIỀN của bạn sẽ bị ảnh hưởng bởi điều đó. Bạn vẫn muốn giữ trạng thái không bị hỏng của các tập hợp của mình.

Tôi thường thêm các sự kiện vào Điều phối viên của mình ở cấp Gốc tổng hợp. Sự kiện này là DomainEvents hoặc ApplicationEvents. Có thể là cả hai và có thể là nhiều người trong số họ. Sau khi trình xử lý lệnh của tôi hoàn tất và tôi quay lại ngăn xếp để mã thực thi trình xử lý lệnh, sau đó tôi kiểm tra Điều phối viên của mình và gửi bất kỳ DomainEvent nào khác. Nếu tất cả những điều này thành công, sau đó tôi đóng giao dịch.

Nếu tôi có bất kỳ Sự kiện Ứng dụng nào, đây là lúc để gửi chúng. Gửi email không nhất thiết cần kết nối mở với cơ sở dữ liệu cũng như mở phạm vi giao dịch.

Tôi đã đi lạc một chút so với câu hỏi ban đầu nhưng điều quan trọng là bạn phải hiểu cách các sự kiện cũng có thể được đối xử khác nhau về mặt khái niệm.

Sau đó, bạn có Sagas .... nhưng đó là CÁCH CÓ THỂ của phạm vi câu hỏi này :)

Nó có ý nghĩa không?

Sự kiện là một sự thật từ quá khứ.

Các lệnh chỉ là một yêu cầu, và do đó có thể bị từ chối.

Một đặc điểm quan trọng của một lệnh là nó chỉ được xử lý một lần bởi một bộ thu duy nhất. Điều này là do một lệnh là một hành động hoặc giao dịch đơn lẻ mà bạn muốn thực hiện trong ứng dụng. Ví dụ, không nên xử lý cùng một lệnh tạo lệnh nhiều lần. Đây là sự khác biệt quan trọng giữa lệnh và sự kiện. Sự kiện có thể được xử lý nhiều lần vì nhiều hệ thống hoặc microservices có thể quan tâm đến sự kiện. 'msdn'

Sau khi xem qua một số ví dụ và đặc biệt là phần trình bày của Greg Young ( http://www.youtube.com/watch?v=JHGkaShoyNs ), tôi đã đi đến kết luận rằng các lệnh là thừa. Chúng chỉ đơn giản là các sự kiện từ người dùng của bạn, họ đã nhấn nút đó. Bạn nên lưu trữ những sự kiện này theo cách giống hệt như các sự kiện khác vì nó là dữ liệu và bạn không biết liệu mình có muốn sử dụng nó trong chế độ xem trong tương lai hay không. Người dùng của bạn đã thêm và sau đó loại bỏ mục đó khỏi giỏ hoặc ít nhất là cố gắng. Sau này, bạn có thể muốn sử dụng thông tin này để nhắc nhở người dùng về điều này sau này.

Chúng được đại diện riêng biệt bởi vì chúng đại diện cho những thứ rất khác nhau. Như @qstarin đã nói các lệnh là các thông báo có thể bị từ chối và nếu thành công sẽ tạo ra một sự kiện. Các lệnh và sự kiện là Dtos, chúng là các thông điệp và chúng có xu hướng trông rất giống nhau khi tạo và thực thể, tuy nhiên từ đó trở đi thì không nhất thiết.

Nếu bạn lo lắng về việc sử dụng lại, thì bạn có thể sử dụng các lệnh và sự kiện làm phong bì cho tải trọng (lộn xộn) của mình

class CreateSomethingCommand
{
    public int CommandId {get; set;}

    public SomethingEnvelope {get; set;}
 }

tuy nhiên, điều tôi muốn biết là tại sao bạn lại hỏi: D tức là bạn có quá nhiều lệnh / sự kiện không?

Ngoài sự khác biệt về khái niệm được đề cập ở trên, tôi nghĩ rằng có một sự khác biệt khác liên quan đến các triển khai chung:

Các sự kiện thường được xử lý trong một vòng lặp nền cần phải thăm dò các hàng đợi sự kiện. Bất kỳ bên nào quan tâm đến việc thực hiện sự kiện, thông thường, có thể đăng ký một lệnh gọi lại được gọi là kết quả của quá trình xử lý hàng đợi sự kiện. Vì vậy, một sự kiện có thể là một hoặc nhiều .

Các lệnh có thể không cần được xử lý theo cách như vậy. Người khởi tạo lệnh thường sẽ có quyền truy cập vào người thực thi lệnh dự kiến. Ví dụ, điều này có thể ở dạng một hàng đợi thông báo đến trình thực thi. Do đó, một lệnh dành cho một thực thể duy nhất .

Tôi nghĩ điều cần thêm vào câu trả lời của quentin-santin là họ:

Đóng gói một yêu cầu dưới dạng một đối tượng, do đó cho phép bạn tham số hóa các máy khách với các yêu cầu khác nhau, yêu cầu hàng đợi hoặc nhật ký và hỗ trợ các hoạt động hoàn tác.

Nguồn .

Bạn không thể tính toán lại một trạng thái dựa trên các lệnh, vì nói chung chúng có thể tạo ra các kết quả khác nhau mỗi khi chúng được xử lý.

Ví dụ, hãy tưởng tượng một GenerateRandomNumberlệnh. Mỗi lần nó được gọi, nó sẽ tạo ra một số ngẫu nhiên khác nhau X. Do đó, nếu trạng thái của bạn phụ thuộc vào số này, mỗi lần bạn tính toán lại trạng thái của mình từ lịch sử lệnh, bạn sẽ nhận được một trạng thái khác.

Sự kiện giải quyết vấn đề này. Khi bạn thực hiện một lệnh, nó tạo ra một chuỗi các sự kiện thể hiện kết quả của việc thực hiện lệnh. Ví dụ, GenerateRandomNumberlệnh có thể tạo ra một GeneratedNumber(X)sự kiện ghi lại số ngẫu nhiên đã tạo. Bây giờ, nếu bạn tính toán lại trạng thái của mình từ nhật ký sự kiện, bạn sẽ luôn nhận được trạng thái tương tự, vì bạn sẽ luôn sử dụng cùng một số được tạo ra bởi một lần thực thi lệnh cụ thể.

Nói cách khác, các lệnh là các hàm với các tác dụng phụ, các sự kiện ghi lại kết quả của một lần thực hiện một lệnh cụ thể.

Lưu ý: Bạn vẫn có thể ghi lại lịch sử các lệnh cho mục đích kiểm tra hoặc gỡ lỗi. Vấn đề là để tính toán lại trạng thái, bạn sử dụng lịch sử của các sự kiện, không phải lịch sử của các lệnh.

Chỉ để thêm vào những câu trả lời tuyệt vời này. Tôi muốn chỉ ra những điểm khác biệt liên quan đến khớp nối.

Các lệnh được hướng tới một bộ xử lý cụ thể. Do đó, có một số mức độ phụ thuộc / kết hợp với bộ khởi tạo Lệnh và bộ xử lý.

Ví dụ: UserServicekhi tạo một người dùng mới sẽ gửi Lệnh "Gửi Email" tới EmailService.

Thực tế là cái UserServicebiết rằng nó cần cái EmailService, cái đó đã được ghép nối. Nếu EmailServicethay đổi lược đồ API của nó hoặc gặp sự cố, nó sẽ ảnh hưởng trực tiếp đến UserServicehàm.

Sự kiện không hướng tới bất kỳ trình xử lý sự kiện cụ thể nào. Do đó, nhà xuất bản sự kiện trở nên liên kết lỏng lẻo. Nó không quan tâm những gì dịch vụ tiêu thụ sự kiện của nó. Việc có 0 khách hàng tham gia một Sự kiện thậm chí còn hợp lệ.

Ví dụ: UserServicekhi tạo một người dùng mới sẽ xuất bản một "Sự kiện do người dùng tạo". Có khả năng một EmailServicecó thể sử dụng sự kiện đó và gửi email cho người dùng.

Ở đây UserServicekhông nhận thức được EmailService. Chúng hoàn toàn tách rời. Nếu sự cố EmailServicehoặc thay đổi các quy tắc kinh doanh, chúng tôi chỉ cần chỉnh sửaEmailService

Cả hai cách tiếp cận đều có giá trị. Khó theo dõi hơn một thiết kế Kiến trúc hướng sự kiện thuần túy vì nó được kết hợp quá lỏng lẻo, đặc biệt là trên các hệ thống lớn. Và một Kiến trúc nặng chỉ huy có mức độ khớp nối cao. Vì vậy, một sự cân bằng tốt là lý tưởng.

Hy vọng điều đó có ý nghĩa.