Event Listeners
Event Listener ها کاملاً در مورد مبادلات هستند. آن‌ها ذاتاً خوب یا بد نیستند—بستگی به زمینه و نیازهای سیستم شما دارد.
1. مقدمه و سؤال کلیدی
- سؤال اصلی
- پاسخ
چه زمانی باید از Event Listener ها استفاده کنیم و چه زمانی باید از آن‌ها اجتناب کنیم؟ آیا درست یا غلط واضحی وجود دارد، یا همیشه یک مبادله است؟
استفاده از Event Listener ها اساساً در مورد مبادلات است. آن‌ها به طور کلی خوب یا بد نیستند—هر مورد استفاده نیاز به بررسی دقیق هزینه‌ها و مزایا دارد.
2. مدیریت رویداد در معماری سیستم
در معماری‌های مدرن، به ویژه Microservices و Event-Driven Architecture، چندین الگو برای مدیریت رویدادها وجود دارد:
- Event Sourcing
- Event Bus
- Business Events
ذخیره تمام تغییرات وضعیت اپلیکیشن به عنوان دنباله‌ای از رویدادها.
سیستمی که به اجزای مختلف اجازه ارتباط از طریق رویدادها را می‌دهد.
رویدادهایی که وقایع معنادار کسب‌وکار را نمایندگی می‌کنند.
تأثیر بر معیارهای کیفیت کد
با افزایش حجم رویدادها، جنبه‌های مختلف کدبیس شما به طرق متفاوتی تحت تأثیر قرار می‌گیرند:
🔻 معیارهای کاهنده
- خوانایی کد
- انسجام ماژول
🔺 معیارهای بهبودیافته
- جداسازی وابستگی‌ها
- انعطاف‌پذیری سیستم
در سیستم‌های ماژولار یا میکروسرویس که جداسازی حیاتی است، Event Listener ها می‌توانند به ویژه ارزشمند باشند.
3. قرارداد تیم برای Event Listener ها
استفاده از Event Listener ها در داخل یک ماژول ممنوع است. آن‌ها فقط باید برای ارتباط بین ماژول‌های جداگانه استفاده شوند.
Event Listener ها به عنوان هماهنگ‌کننده
Event listener ها باید فقط بر مسئولیت‌های هماهنگی متمرکز باشند، نه اجرای منطق اصلی کسب‌وکار. آن‌ها باید تا حد امکان سبک باقی بمانند با:
- واگذاری منطق کسب‌وکار به لایه‌های سرویس اختصاصی
- اجتناب از شرطی‌های پیچیده یا قوانین کسب‌وکار
- کمینه‌سازی عملیات همزمان و فراخوانی‌های مسدودکننده
- نگه‌داشتن listener متمرکز بر مسیریابی و هماهنگی
این رویکرد جداسازی واضح دغدغه‌ها را حفظ می‌کند و قابلیت نگهداری را بهبود می‌بخشد.
مثال سناریو
✅ مجاز: ماژول A رویدادی شلیک می‌کند که ماژول B به آن گوش می‌دهد
❌ مجاز نیست: ماژول A مستقیماً متدهای ماژول B را فراخوانی می‌کند
اتصال مستقیم ماژول‌ها استقلال را کاهش می‌دهد و سیستم را سخت‌تر می‌کند. رویدادها معماری شل‌تر و قابل نگهداری‌تری ایجاد می‌کنند.
4. راهنمایی‌های پیاده‌سازی
سناریوهای رایج
ماتریس تصمیم‌گیری
| سناریو | وضعیت | تأثیر |
|---|---|---|
| اتصال مستقیم بین انتیتی‌های دو ماژول | ❌ ممنوع | ماژولاریتی را نقض می‌کند |
| فراخوانی مستقیم سرویس از ماژول دیگر | ⚠️ توصیه نمی‌شود | باعث اتصال محکم می‌شود |
| شلیک رویداد از ماژول A و گوش دادن در ماژول B | ✅ مجاز | اتصال شل را ترویج می‌کند |
در صورت تردید، رویکرد مبتنی بر رویداد را برای ارتباط بین ماژولی ترجیح دهید.
5. استاندارد Business Events
یک Business Event وقوع معنادار کسب‌وکاری را نمایندگی می‌کند که بخش‌های دیگر سیستم ممکن است به آن علاقه‌مند باشند.
ویژگی‌های کلیدی
- چرا از Business Events استفاده کنیم؟
- چه زمانی شلیک کنیم
- موارد استفاده رایج
- معماری شما را برای آینده آماده می‌کند
- اتصال شل بین ماژول‌ها را امکان‌پذیر می‌کند
- سیستم را قابل مشاهده‌تر می‌کند
- هنگامی که عمل معنادار کسب‌وکاری رخ می‌دهد
- حتی اگر listener فعلی وجود نداشته باشد
- برای دغدغه‌های مقطعی
- ارسال اعلان‌ها
- نظارت بر سیستم
- حسابرسی و لاگ‌گیری
- راه‌اندازی گردش کارها
// مثال: شلیک یک business event
class OrderService {
async completeOrder(orderId) {
// منطق کسب‌وکار...
eventBus.publish('order.completed', { orderId, timestamp: Date.now() });
}
}
6. چارچوب تصمیم‌گیری
چه زمانی از Event Listener ها استفاده کنیم
- بین ماژول‌های مستقل ارتباط برقرار می‌کنید
- جداسازی مهم‌تر از اتصال مستقیم است
- چندین جزء نیاز به واکنش به یک رویداد دارند
چه زمانی از Event Listener ها اجتناب کنیم
- ارتباط در داخل یک ماژول باقی می‌ماند
- اتصال مستقیم ساده‌تر و قابل نگهداری‌تر است
- به ارتباط همزمان نیاز دارید
7. راهنمایی‌های نهایی
- بازسازی هر event listener درون ماژولی که یافت می‌شود
- حفظ ارتباط مبتنی بر رویداد بین ماژولی
- مستندسازی تمام business event ها و اهداف آن‌ها
حتی اگر listener فعلی وجود نداشته باشد، شلیک business event ها برای وقایع مهم به حفظ انعطاف‌پذیری برای نیازهای آینده کمک می‌کند.