📡 معماری رویدادمحور در یک نگاه تصور کنید سیستمی دارید که منتظر دستور مستقیم نمی‌ماند، بلکه به سیگنال‌های محیطی گوش می‌دهد و بلافاصله واکنش نشان می‌دهد. این جوهره سبک معماری رویدادمحور است؛ تغییری بنیادین از مدل سنتی درخواست-پاسخ که در آن هر عملیات یک زنجیره همگام و گام‌به‌گام است. با جداسازی نگرانی‌ها بین تولیدکننده و مصرف‌کننده رویداد، سیستمی می‌سازید که نه تنها بسیار پاسخگو است، بلکه در برابر تغییرات نیز انعطاف‌پذیری بالایی دارد. 🔄 درخواست‌محور در برابر رویدادمحور بسیاری از برنامه‌نویسان با مدل درخواست‌محور خو گرفته‌اند؛ مدلی که در آن یک رابط کاربری یا لایه API به عنوان ارکستراتور عمل کرده و درخواست‌ها را به پردازشگرهای خاص هدایت می‌کند. اگرچه این مدل شهودی است، اما باعث ایجاد اتصال شدید شده و با رشد سیستم به یک گلوگاه تبدیل می‌شود. مشکل اصلی که این فصل به آن می‌پردازد، چگونگی عبور از این جریان خشک و قطعی به سمت مدلی منعطف و ناهمگام است که وظایف حجیم و عملیاتی را بدون فروپاشی تحت فشار وابستگی‌ها مدیریت کند. 📨 توپولوژی کارگزار در قلب این معماری دو توپولوژی اصلی قرار دارد. توپولوژی کارگزار (Broker Topology) زمانی انتخاب ایده‌آل است که به پاسخگویی بالا و سادگی نیاز دارید. این مدل بر یک کارگزار پیام سبک تکیه دارد تا رویدادها را به صورت زنجیره‌ای توزیع کند. آن را مانند سیستم اعلام عمومی در یک ایستگاه قطار تصور کنید: مسئول اعلام می‌کند قطار رسیده است و بخش‌های مختلف (نظافت، امنیت، بلیت‌فروشی) مستقل از هم واکنش نشان می‌دهند. بدون این مدل، به یک مدیر مرکزی نیاز داشتید که تمام حرکات را هماهنگ کند که در صورت خرابی آن، کل سیستم از کار می‌افتاد. 🎼 توپولوژی میانجی در مقابل، توپولوژی میانجی (Mediator Topology) برای زمانی است که به کنترل دقیق بر جریان‌های کاری پیچیده نیاز دارید. اگر منطق تجاری شما ایجاب می‌کند که گام الف حتماً قبل از گام ب تمام شود، میانجی مانند رهبر ارکستر عمل می‌کند. این مؤلفه وضعیت را حفظ کرده و مدیریت خطا را بر عهده می‌گیرد. این برای عملیاتی مانند تراکنش‌های مالی که یکپارچگی در آن‌ها غیرقابل مذاکره است، حیاتی است. بدون میانجی، مدیریت این توالی‌های پیچیده در مؤلفه‌های توزیع‌شده، کابوسی از مدیریت وضعیت خواهد بود. ⏳ قابلیت‌های ناهمگام و تحمل خطا این توپولوژی‌ها به شدت به قابلیت‌های ناهمگام متکی هستند که به مؤلفه‌ها اجازه می‌دهد رویداد را ارسال کرده و به کار خود ادامه دهند. با این کار، مقیاس‌پذیری به شدت افزایش می‌یابد. اما این موضوع چالش‌هایی در تحمل خطا و جلوگیری از دست رفتن داده‌ها ایجاد می‌کند. وقتی فرآیندی شکست می‌خورد، نمی‌توانید صرفاً یک خطای ۵۰۰ به کاربر برگردانید. باید از استراتژی‌های قدرتمندی مانند صف‌های پیام پایدار استفاده کنید تا هیچ رویدادی گم نشود. مانند خدمات پستی: حتی اگر کامیون خراب شود، بسته در سیستم باقی می‌ماند تا زمانی که دوباره مسیردهی شود. 📣 قابلیت‌های پخش قابلیت‌های پخش (Broadcast) با اجازه دادن به یک رویداد برای تحریک چندین عمل غیرمرتبط، سطح نهایی انعطاف‌پذیری را فراهم می‌کنند. شما می‌توانید یک قابلیت جدید (مانند موتور تحلیل داده) را صرفاً با گوش دادن به جریان‌های موجود اضافه کنید، بدون اینکه کد تولیدکنندگان اصلی را تغییر دهید. برای سناریوهایی که نیاز به پاسخ دارند، الگوی درخواست-پاسخ با استفاده از شناسه همبستگی (Correlation ID) اجازه می‌دهد که ماهیت ناهمگام سیستم، جریان منطقی داده را مختل نکند. ⚖️ انتخاب بین دو مدل انتخاب بین این مدل‌ها یک بده‌بستان مهم است. سیستم‌های درخواست‌محور برای کارهای داده‌محور (مانند دریافت پروفایل کاربر) عالی هستند. سیستم‌های رویدادمحور برای جریان‌های کاری پیچیده که نیاز به پاسخگویی بالا دارند، برتری دارند. اغلب، شما به سمت معماری‌های ترکیبی خواهید رفت تا کنترل را با پاسخگویی متعادل کنید. در نهایت، درک رتبه‌بندی ویژگی‌های معماری به شما کمک می‌کند تا تأثیر انتخاب‌های خود را بر در دسترس بودن و قابلیت نگهداری بسنجید. [ ] تشخیص دهید که آیا یک فرآیند تجاری داده‌محور (درخواست‌محور) است یا عملیات‌محور (رویدادمحور). [ ] انتخاب توپولوژی مناسب (کارگزار در مقابل میانجی) بر اساس نیاز به کنترل جریان کاری یا پاسخگویی. [ ] پیاده‌سازی صف‌های پیام پایدار برای تضمین تحویل و جلوگیری از دست رفتن داده‌ها. [ ] استفاده از شناسه همبستگی برای مدیریت الگوهای درخواست-پاسخ در محیط ناهمگام. [ ] طراحی پردازشگرهای رویداد به صورت جدا از هم و توسعه‌پذیر برای رشد آتی سیستم. [ ] تعریف استراتژی‌های مدیریت خطا که ماهیت توزیع‌شده پردازش رویداد را در نظر می‌گیرند.