سخنران: David Boyne
رویداد: GOTO EDA Day London 2024
لینک ویدئو: https://www.youtube.com/watch?v=VLUvfIm9wnQ
معماری رویدادمحور (Event-Driven Architecture) در چند سال اخیر به یکی از پرطرفدارترین سبکهای معماری تبدیل شده است؛ وعدهاش هم وسوسهکننده است: سرویسهایی مستقل که بهجای فراخوانی مستقیم یکدیگر، فقط رویداد منتشر میکنند و هر مصرفکنندهای آزاد است هر طور میخواهد واکنش نشان دهد. اما دیوید در این سخنرانی در رویداد تخصصی GOTO EDA Day لندن، روی دیگر سکه را نشان میدهد: همان جادویی که سیستم شما را منعطف میکند، اگر مهارش نکنید، آن را به کلافی سردرگم از رویدادهای بیصاحب و جریانهای نامرئی تبدیل میکند. بوین سالها تجربه کار با تیمهای واقعی را دارد و همین باعث شده حرفهایش کمتر شبیه تبلیغ و بیشتر شبیه گزارشی صادقانه از میدان باشد.
بوین بحث را از جذابیتهای واقعی EDA شروع میکند: جداسازی زمانی و مکانی سرویسها، مقیاسپذیری مستقل، امکان افزودن مصرفکننده جدید بدون دستزدن به تولیدکننده، و همراستایی طبیعی با رویدادهای دنیای کسبوکار. اما بلافاصله سراغ نکته اصلی میرود: پیچیدگی در EDA ناگهانی نمیآید، بلکه آرامآرام و رویداد به رویداد انباشته میشود. تیمی که با ده رویداد شروع کرده، دو سال بعد با صدها نوع رویداد روبهروست که هیچکس فهرست کاملشان را ندارد: رویدادهایی با نامهای ناسازگار، اسکیماهای مستندنشده، رویدادهای تکراری که چند تیم بیخبر از هم منتشر میکنند، و مصرفکنندگانی که کسی نمیداند به چه چیزی وابستهاند. جریان کنترل که در سیستم همزمان با یک پشته فراخوانی قابل ردیابی بود، حالا در دل بروکرها و صفها پخش شده و پاسخ به سادهترین سوال «اگر این رویداد را تغییر بدهم چه میشکند؟» به تحقیقی چندروزه تبدیل میشود.
هسته پیشنهادی سخنرانی این است که رویدادها را باید مثل API عمومی و بهعنوان «قرارداد» جدی بگیریم، نه پیامهایی درجهدو. این یعنی چند تمرین مشخص: طراحی آگاهانه رویدادها (تصمیم صریح بین رویداد لاغر صرفاً اعلانی و رویداد چاق حامل وضعیت، چون هر کدام نوع متفاوتی از وابستگی میسازد)، قراردادهای اسکیمای صریح و نسخهبندیشده، قواعد نامگذاری سراسری، و مهمتر از همه، مالکیت روشن: هر رویداد باید تیم صاحب و پاسخگو داشته باشد. بوین روی «کشفپذیری» تأکید ویژه دارد (مصرفکننده بالقوه باید بتواند بفهمد چه رویدادهایی وجود دارند، چه معنایی دارند و اسکیمایشان چیست) و اینجاست که ابزارهایی مثل EventCatalog و رجیستری اسکیما از «امکانات لوکس» به زیرساخت حیاتی تبدیل میشوند. پیام پایانی او درباره حاکمیت (Governance) است: نه کمیتههای سنگین، بلکه گاردریلهای سبک و خودکار (استانداردها، قالبها و بررسیهای خودکار در CI) که بگذارند تیمها سریع بمانند اما آشوب تولید نکنند.
چیزی که این سخنرانی را برای من ارزشمند میکند، جابهجاکردن محل بحث است: بیشتر محتوای آموزشی EDA درباره «ساختن» است مانند بروکر کدام باشد و الگوی Saga چطور پیاده شود اما بوین درباره «زیستن» با EDA حرف میزند؛ درباره سال دوم و سوم، وقتی هیجان اولیه فروکش کرده و هزینه واقعی خودش را نشان میدهد. بوین نشان میدهد این پیچیدگی جابهجاشده دقیقاً کجا مینشیند (در دانش سازمانی). در سیستم رویدادمحور، معماری واقعی نه در کد که در مجموعه قراردادهای بین تیمهاست، و اگر این قراردادها مستند و مدیریت نشوند، شما عملاً معماریای دارید که فقط در ذهن چند نفر وجود دارد. به نظرم درس بزرگتر این است که مستندسازی در EDA برخلاف تصور رایج، یک کار «بعداً انجام میدهیم» نیست؛ بخشی از خود معماری است.
اگر همین حالا سیستم رویدادمحور دارید یا در حال طراحی آن هستید، چند اقدام مشخص از دل این سخنرانی درمیآید. اول، قبل از نوشتن حتی یک رویداد جدید، سند کوتاهی از قواعد نامگذاری و ساختار رویدادها بنویسید و آن را در قالب یک قالب آماده (Template) به تیمها بدهید؛ هزینهاش یک روز است و جلوی سالها ناسازگاری را میگیرد. دوم، یک کاتالوگ رویداد راه بیندازید که برای هر رویداد، مالک، اسکیما، نسخه و مصرفکنندگان شناختهشده را ثبت کند و بهروزماندنش را در فرایند بازبینی کد اجباری کنید. سوم، برای تغییر اسکیماها از همان ابتدا سیاست نسخهبندی تعیین کنید؛ تجربه نشان داده «فعلاً نسخه نمیخواهیم» گرانترین جمله EDA است. در پروژههایی مثل بازیهای آنلاین که رویدادهای حیاتی فراوانی دارند این نظم از روز اول تعیین میکند که دو سال بعد میتوانید ویژگی جدید را در یک هفته اضافه کنید یا باید یک ماه باستانشناسی رویدادها انجام دهید.
سخنرانی بوین یادآوری بهموقعی است برای همه ما که فریفته زیبایی معماری رویدادمحور شدهایم: EDA پیچیدگی را از لحظه استقرار به دوران بهرهبرداری منتقل میکند و اگر برای آن دوران برنامه نداشته باشید، بدهی فنیتان بهجای کد، در نقشه ذهنی سازمان انباشته میشود. درسهای کلیدی: رویداد یعنی قرارداد عمومی، پس مثل API با آن رفتار کنید؛ کشفپذیری و مالکیت را از روز اول بسازید؛ و حاکمیت را نه با کمیته، که با گاردریلهای خودکار اعمال کنید. برای هر تیمی که بیش از دهها نوع رویداد در تولید دارد، این ویدیو کمتر از یک ساعت وقت میگیرد و احتمالاً ماهها دردسر آینده را کم میکند.
اين مطلب، بخشی از تمرينهای درس معماری نرمافزار در دانشگاه شهيد بهشتی است.
