Event-Driven Architecture چیست؟
سبکی از معماری که در آن سرویسها بهجای فراخوانی مستقیم هم، رویداد (Event) منتشر میکنند و سرویسهای دیگر به آن Subscribe میشوند.
چرا مهم است؟
سرویس تولیدکننده رویداد هیچ اطلاعی از مصرفکنندهها ندارد؛ این Decoupling باعث میشود بتوان سرویس جدید اضافه کرد یا یکی را از کار انداخت بدون دستکاری بقیه سیستم.
اجزای اصلی
- Producer: رویدادی مثل
OrderCreatedرا منتشر میکند. - Message Broker: واسطه انتقال رویداد (مثل RabbitMQ یا Kafka).
- Consumer: به آن رویداد Subscribe میشود و مستقل واکنش نشان میدهد.
مثال جریان
Order Service --(OrderCreated Event)--> Message Broker --> Notification Service
\\--> Inventory Service
\\--> Email Service
هر سه Consumer مستقل از هم و مستقل از Order Service به رویداد واکنش نشان میدهند.
نکات مهم
- ارتباط Asynchronous است؛ Producer منتظر پاسخ Consumerها نمیماند.
- افزودن یک Consumer جدید نیازی به تغییر کد Producer ندارد — فقط باید به همان رویداد Subscribe کند.
- باید بین رویدادهای «اتفاق افتاد» (Domain Event، مثل
OrderCreated) و پیامهای Command (دستور برای انجام کاری) تمایز قائل شد.
اشتباه رایج
❌ زنجیرهکردن بیشازحد رویدادها (سرویس A رویداد B را منتشر میکند، B رویداد C را، C رویداد D را...) تا جایی که دنبالکردن مسیر واقعی یک عملیات در کل سیستم غیرممکن میشود — این حالت را Distributed Monolith یا Distributed Big Ball of Mud مینامند.
خلاصه
در Event-Driven Architecture سرویسها با انتشار و اشتراک رویداد از طریق یک Message Broker ارتباط برقرار میکنند، نه با فراخوانی مستقیم هم. این کار Decoupling و مقیاسپذیری مستقل هر سرویس را ممکن میکند. زنجیرهکردن بیشازحد رویدادها ردیابی جریان سیستم را دشوار میکند.