عنوان سخنرانی: Residues: Time, Change and Uncertainty in Software Architecture
همایش: GOTO Copenhagen 2025
سخنران: Barry O’Reilly
مدت سخنرانی: حدود ۴۷ دقیقه
لینک ویدئو: https://youtu.be/D8qQUHrksrE?si=-EBSeU6zVS-Lu07A
یکی از پرسش‌هایی که همیشه در معماری نرم‌افزار مطرح می‌شود این است که چگونه می‌توان سیستمی طراحی کرد که با تغییر نیازمندی‌ها، رشد کسب‌وکار و رخدادهای پیش‌بینی‌نشده از بین نرود. Barry O’Reilly در این سخنرانی به‌جای معرفی یک سبک معماری یا فناوری جدید، نگاه بنیادی‌تری به این مسئله دارد. او معتقد است مشکل اصلی معماری نرم‌افزار، فقط انتخاب میان میکروسرویس، مونولیت، معماری رویدادمحور یا فناوری‌های مختلف نیست؛ مشکل مهم‌تر این است که معماری در یک محیط ثابت ساخته نمی‌شود. محیط کسب‌وکار، رفتار کاربران، قوانین، بازار و فناوری‌ها دائماً تغییر می‌کنند، درحالی‌که ساختار نرم‌افزار معمولاً بسیار خشک‌تر و محدودتر است.
پیش از دیدن این سخنرانی، عدم قطعیت را بیشتر به‌عنوان مشکلی می‌دیدم که باید با جمع‌آوری دقیق‌تر نیازمندی‌ها و پیش‌بینی ریسک‌ها کاهش پیدا کند. اما نکته اصلی ارائه این است که عدم قطعیت را نمی‌توان به‌طور کامل حذف کرد؛ زیرا معمولا همان اتفاق‌هایی بیشترین آسیب را به سیستم وارد می‌کنند که از قبل در فهرست ریسک‌ها قرار نگرفته‌اند. به همین دلیل، معمار باید به‌جای تلاش برای پیش‌بینی دقیق آینده، معماری را برای روبه‌روشدن با آینده‌های متفاوت آماده کند.
سخنران برای توضیح این دیدگاه، نظریه‌ای با عنوان Residuality Theory معرفی می‌کند. در این نظریه، سیستم نرم‌افزاری فقط به‌صورت مجموعه‌ای از کامپوننت‌ها و فرایندها دیده نمی‌شود، بلکه به‌صورت مجموعه‌ای از «باقی‌مانده‌ها» یا Residue ها مدل می‌شود. Residue بخشی از معماری است که پس از واردشدن یک فشار یا تغییر جدی، همچنان قابل استفاده باقی می‌ماند. در نتیجه، سؤال اصلی دیگر این نیست که «در حالت عادی اجزای سیستم چگونه با یکدیگر کار می‌کنند؟»، بلکه این است که «وقتی شرایط عادی از بین رفت، چه چیزی از سیستم باقی می‌ماند و هنوز می‌تواند به کار خود ادامه دهد؟»
یکی از بخش‌های جالب سخنرانی، ارتباط معماری نرم‌افزار با علم پیچیدگی است. در یک سیستم پیچیده، تعداد ارتباط‌ها و حالت‌های احتمالی آن‌قدر زیاد است که بررسی همه آن‌ها عملاً امکان‌پذیر نیست. بااین‌حال، سیستم معمولا به تعداد محدودی وضعیت خاص تمایل پیدا می‌کند که در این نظریه Attractor نامیده می‌شوند. برای مثال، ممکن است چند رخداد ظاهرا متفاوت، سیستم را به وضعیت مشترکی مانند قطع کامل سرویس، ازدست‌رفتن امکان پرداخت یا وابستگی شدید به یک جزء خاص هدایت کنند. بنابراین، به‌جای پیش‌بینی تمام رخدادهای ممکن، باید این وضعیت‌های تکرارشونده و خطرناک را شناسایی کرد.
فرایند پیشنهادی Residuality با یک معماری اولیه و نسبتا ساده آغاز می‌شود که مسئله اصلی را حل می‌کند. سپس تیم، مجموعه‌ای از Stressor ها یا عوامل فشار را به معماری وارد می‌کند. این فشارها می‌توانند فنی باشند، مانند قطع شبکه یا ازکارافتادن پایگاه داده؛ اما ممکن است به تغییر قوانین، رفتار غیرمنتظره کاربران، تغییر بازار یا حتی سناریوهای بسیار بعید مربوط باشند. هدف از این کار، پیش‌بینی دقیق آینده نیست، بلکه خارج‌کردن ذهن تیم از فرضیات محدود فعلی است. پس از هر فشار بررسی می‌شود که معماری به چه وضعیتی وارد می‌شود، چه اجزایی از کار می‌افتند و چه بخش‌هایی باقی می‌مانند. سپس Residue های به‌دست‌آمده با یکدیگر ترکیب می‌شوند تا معماری نهایی در برابر طیف گسترده‌تری از تغییرات دوام بیاورد.
در سخنرانی، این مفاهیم با نمونه‌ای از سامانه شارژ خودروهای الکتریکی توضیح داده می‌شوند. همچنین از تحلیل سرایت یا Contagion Analysis برای بررسی این موضوع استفاده می‌شود که چگونه اختلال در یک بخش می‌تواند به بخش‌های دیگر منتقل شود و باعث شکست زنجیره‌ای شود. این مثال نشان می‌دهد که گاهی مشکل اصلی، خراب‌شدن یک کامپوننت نیست، بلکه میزان وابستگی اجزا به یکدیگر و سرعت گسترش اختلال در کل سیستم است. سخنران با کمک مفاهیمی مانند شبکه‌های کافمن و تحلیل روابط میان اجزا، تلاش می‌کند پیچیدگی و سرایت شکست را به شکلی قابل‌بررسی‌تر نمایش دهد.
برداشت من این است که Residuality قصد ندارد اهمیت نیازمندی‌ها، تجربه مهندسی یا مدیریت ریسک را کاملا انکار کند. ارزش اصلی آن در این است که اعتماد بیش‌ازحد ما به پیش‌بینی را به چالش می‌کشد. حتی کامل‌ترین سند نیازمندی‌ها نیز بر اساس دانسته‌های امروز نوشته می‌شود، درحالی‌که معماری باید سال‌ها در محیطی فعالیت کند که بخشی از آن هنوز ناشناخته است. به همین دلیل، معماری مناسب فقط معماری‌ای نیست که نیاز فعلی را به‌درستی پیاده‌سازی کند؛ بلکه باید بتواند در شرایطی که فرضیات اولیه دیگر معتبر نیستند نیز بخشی از ارزش خود را حفظ کند.
یکی از جمله‌های کلیدی این دیدگاه را می‌توان این‌گونه خلاصه کرد: معماری نباید فقط طراحی شود، بلکه باید مانند یک مدل، تحت فشار «آموزش» داده شود. برای ارزیابی نتیجه نیز می‌توان معماری اولیه و معماری اصلاح‌شده را با مجموعه جدیدی از Stressor ها آزمایش کرد و بررسی کرد کدام‌یک در برابر رخدادهای ناشناخته دوام بیشتری دارند. این نگاه، تصمیم‌گیری معماری را از یک فعالیت مبتنی بر سلیقه یا تجربه فردی، به فرایندی شفاف‌تر، قابل آزمایش‌تر و قابل آموزش تبدیل می‌کند.
در مجموع، این سخنرانی باعث شد معماری نرم‌افزار را کمتر به عنوان یک نمودار ثابت و بیشتر به عنوان ساختاری ببینم که باید در برابر حرکت دائمی محیط اطراف خود دوام بیاورد. وظیفه معمار این نیست که آینده را دقیق پیش‌بینی کند؛ بلکه باید محدودیت پیش‌بینی را بپذیرد، معماری را در معرض فشارهای متنوع قرار دهد و ساختاری ایجاد کند که با تغییر یک فرض، تمام سیستم فرو نریزد. به نظرم، این نوع نگاه برای سیستم‌هایی که در محیط‌های پیچیده، متغیر و غیرقابل‌پیش‌بینی فعالیت می‌کنند، بسیار کاربردی و ارزشمند است.
منابع
ویدئوی رسمی سخنرانی در کانال GOTO Conferences :
https://youtu.be/D8qQUHrksrE?si=-EBSeU6zVS-Lu07A
صفحه رسمی سخنرانی در GOTO :
https://gotopia.tech/sessions/3595/residues-time-change-and-uncertainty-in-software-architecture
گزارش InfoQ درباره Residuality Theory :
https://www.infoq.com/news/2025/10/architectures-residuality-theory
معرفی کتاب Residues در GOTO :
https://gotopia.tech/books/120/residues-time-change-and-uncertainty-in-software-architecture
اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيدبهشتی است 🌱
