یک باگ به production می‌رود. کاربر ناراضی می‌شود، پشتیبانی درگیر می‌شود و تیم فنی دنبال علت می‌گردد. در چنین لحظه‌ای معمولاً اولین سؤال این است: «چرا QA این را نگرفت؟»

این سؤال از یک نگرانی واقعی می‌آید. کسی انتظار دارد قبل از رسیدن خطا به کاربر، یک جایی در مسیر جلوی آن گرفته شود. اما همین سؤال، اگر دقیق بررسی نشود، ما را به یک برداشت ساده‌انگارانه می‌رساند: اینکه کیفیت چیزی است که در انتهای مسیر، توسط یک نقش جدا، به محصول اضافه می‌شود.

به نظرم این برداشت ریشه‌ی خیلی از سوءتفاهم‌های تیم‌های نرم‌افزاری است. این متن علیه QA نیست و قرار نیست تخصص تست و کیفیت را بی‌ارزش کند. مسئله این است که QA نباید جایگزین مسئولیت تیم شود. کیفیت اگر در فهم مسئله، طراحی، کدنویسی، تست، انتشار و بازخورد ساخته نشده باشد، در آخر مسیر فقط دیرتر خراب بودنش را می‌فهمیم.

پس ایده‌ی اصلی این متن ساده است: کیفیت مسئولیت مشترک تیم است؛ اما مسئولیت مشترک نباید به بی‌مالکیتی تبدیل شود. هر نقش باید مالک کیفیت همان تصمیمی باشد که روی آن اثر می‌گذارد.

کیفیت نرم‌افزار یک ایستگاه پایانی نیست. کیفیت، نتیجه‌ی زنجیره‌ای از تصمیم‌هاست: اینکه مسئله چقدر درست فهمیده شده، راه‌حل چقدر ساده طراحی شده، کد چقدر خواناست، تست‌ها چقدر قابل اعتمادند، انتشار چقدر امن است و تیم بعد از انتشار چقدر سریع بازخورد می‌گیرد.

پس پاسخ کوتاه این است: مسئول کیفیت، کل تیم است.

اما همین پاسخ هم اگر دقیق نشود، خطرناک است. چون «همه مسئول‌اند» گاهی در عمل یعنی «هیچ‌کس مسئول نیست». کیفیت باید مسئولیت مشترک باشد، اما مالکیت آن در هر نقطه باید روشن بماند.

کیفیت یعنی چه؟​

قبل از اینکه بپرسیم چه کسی مسئول کیفیت است، باید روشن کنیم کیفیت یعنی چه.

کیفیت فقط نبودن باگ نیست. نرم‌افزاری ممکن است بدون خطای فنی جدی کار کند، اما همچنان بی‌کیفیت باشد؛ چون مسئله‌ی اشتباهی را حل می‌کند، تجربه‌ی کاربر بدی دارد، کند است، تغییر دادنش سخت است، خطاهایش دیده نمی‌شود یا بعد از انتشار به‌سختی قابل نگهداشت است.

از این زاویه، کیفیت چند لایه دارد:

• کیفیت محصولی: آیا مسئله‌ی درستی را حل کرده‌ایم؟
• کیفیت طراحی: آیا راه‌حل ساده، قابل فهم و قابل تغییر است؟
• کیفیت فنی: آیا کد خوانا، تست‌پذیر و قابل نگهداشت است؟
• کیفیت عملیاتی: آیا سیستم در اجرا قابل اتکا، قابل مشاهده و قابل بازگشت است؟
• کیفیت انسانی: آیا تیم می‌تواند درباره‌ی ریسک‌ها صادقانه حرف بزند؟

وقتی کیفیت را فقط به «تست شدن» تقلیل می‌دهیم، بخش بزرگی از واقعیت را از دست می‌دهیم.

سوءتفاهم رایج: QA آخر مسیر کیفیت را تضمین می‌کند​

در خیلی از تیم‌ها، مسیر کار شبیه این است: محصول تعریف می‌شود، توسعه‌دهنده پیاده‌سازی می‌کند، بعد QA تست می‌کند و در نهایت محصول منتشر می‌شود.

این مدل در ظاهر مرتب است. نقش‌ها جدا هستند و هرکس ظاهراً کار خودش را دارد. اما مشکل اصلی اینجاست که کیفیت از محل تولید جدا می‌شود.

ابهام نیازمندی، طراحی پیچیده، کد شکننده، تست‌ناپذیری، خطای مدیریت وضعیت، نبودن مشاهده‌پذیری و تصمیم‌های عجولانه معمولاً همان‌جایی ساخته می‌شوند که محصول و کد ساخته می‌شوند؛ نه در مرحله‌ی تست نهایی.

QA می‌تواند بخشی از این مشکلات را کشف کند، اما نمی‌تواند کیفیت را بعد از تولید به محصول تزریق کند. اگر کیفیت در طراحی و توسعه ساخته نشده باشد، QA فقط می‌تواند دیرتر خبر بد را به تیم بدهد.

این تفاوت مهمی است: کشف خطا با ساختن کیفیت یکی نیست.

نگاه فنی: توسعه‌دهنده نزدیک‌ترین فرد به کیفیت است​

از زاویه‌ی فنی، توسعه‌دهنده نزدیک‌ترین فرد به کیفیت است. کسی که کد را می‌نویسد، بهتر از هرکس می‌داند تصمیم‌های فنی کجا گرفته شده‌اند، پیچیدگی کجا پنهان شده، چه چیزی تست‌پذیر نیست و کدام بخش در آینده شکننده خواهد شد.

کدی که خوانا نیست، با تست نهایی خوانا نمی‌شود. طراحی‌ای که بی‌دلیل پیچیده است، با QA ساده نمی‌شود. خطایی که درست مدیریت نشده، با چند سناریوی دستی قابل اتکا نمی‌شود. نبودن لاگ، متریک و مشاهده‌پذیری هم چیزی نیست که آخر مسیر با یک چک‌لیست حل شود.

به همین دلیل، تست واحد، بازبینی کد، طراحی ساده، مدیریت خطا، مشاهده‌پذیری و بازخورد سریع بخشی از کار توسعه‌اند، نه کارهای اضافه و تجملی.

در کتاب Software Engineering at Google روی همین ایده تأکید می‌شود که تست‌های کوچک و سریع فقط برای پیدا کردن باگ نیستند؛ برای افزایش بهره‌وری مهندس‌اند. چون توسعه‌دهنده می‌تواند مدام بازخورد بگیرد، با اطمینان تغییر بدهد و خطا را نزدیک به همان نقطه‌ای پیدا کند که ساخته شده است.

هرچه بازخورد به کد نزدیک‌تر باشد، اصلاح ارزان‌تر است. هرچه بازخورد دیرتر برسد، هزینه‌ی فهمیدن، بازسازی ذهنی و اصلاح بیشتر می‌شود.

نگاه تست: تست بیشتر همیشه کیفیت بیشتر نیست​

یکی از خطاهای رایج این است که فکر کنیم اگر تست‌های انتهایی بیشتری داشته باشیم، کیفیت بهتر می‌شود.

تست‌های سراسری لازم‌اند. بالاخره باید بفهمیم کاربر در مسیر واقعی با چه چیزی روبه‌رو می‌شود. اما اگر ستون اصلی اطمینان تیم، تست‌های انتهابه‌انتها باشد، معمولاً با سیستمی کند، شکننده و سخت‌عیب‌یاب روبه‌رو می‌شویم.

وقتی یک تست سراسری می‌شکند، همیشه روشن نیست مشکل از کجاست: رابط کاربری، شبکه، داده، سرویس پشتی، زمان‌بندی، وابستگی بیرونی یا خود تست؟ این نوع تست‌ها برای پوشش دادن رفتار کل سیستم مفیدند، اما برای پیدا کردن سریع ریشه‌ی خطا همیشه ابزار خوبی نیستند.

ایده‌ی هرم تست دقیقاً همین را توضیح می‌دهد: بیشتر تست‌ها باید کوچک، سریع و نزدیک به کد باشند؛ بخشی از تست‌ها یکپارچگی اجزای مهم را بررسی کنند؛ و تعداد محدودتری تست، کل مسیر سیستم را از ابتدا تا انتها بسنجد.

پس هدف، زیاد کردن کورکورانه‌ی تست نیست. هدف، ساختن چرخه‌ی بازخورد درست است.

نگاه QA: پلیس کیفیت یا کاتالیزور کیفیت؟​

نقد مدل سنتی QA به معنی بی‌ارزش دانستن تخصص کیفیت نیست. برعکس، هرچه تیم کیفیت را جدی‌تر بگیرد، به نگاه انتقادی، سناریوسازی و کشف ریسک بیشتر نیاز دارد. مشکل از جایی شروع می‌شود که QA به جای توانمند کردن تیم، به ایستگاه آخر تأیید تبدیل می‌شود.

در چنین مدلی توسعه‌دهنده ممکن است فکر کند «اگر مشکلی بود QA می‌گیرد». مدیر محصول ممکن است فکر کند «اگر نیازمندی مبهم بود، در تست معلوم می‌شود». مدیر تیم هم ممکن است خیال کند چون یک مرحله‌ی کنترل وجود دارد، پس کیفیت مدیریت شده است.

اما نقش سالم QA چیز دیگری است.

QA می‌تواند کاتالیزور کیفیت باشد؛ یعنی کسی که کمک می‌کند تیم ریسک‌ها را زودتر ببیند، سناریوهای مهم را بهتر طراحی کند، نقاط کور محصول را پیدا کند و چرخه‌ی بازخورد را بهتر کند.

QA خوب فقط دنبال باگ نمی‌گردد. QA خوب سؤال‌های سخت می‌پرسد: اگر کاربر این مسیر را نیمه‌کاره رها کند چه می‌شود؟ اگر سرویس بیرونی کند شود چه می‌شود؟ اگر داده‌ی قدیمی برسد چه می‌شود؟ اگر نیازمندی را اشتباه فهمیده باشیم چه؟ اگر این تصمیم در مقیاس بزرگ تکرار شود چه هزینه‌ای دارد؟

این نگاه، QA را از نقش «تأییدکننده‌ی آخر مسیر» به نقش «کمک‌کننده به تفکر کیفیت‌محور» تبدیل می‌کند.

نگاه محصول: کیفیت فقط مسئله‌ی فنی نیست​

بخشی از کیفیت قبل از نوشتن اولین خط کد ساخته یا خراب می‌شود.

اگر مسئله درست فهمیده نشده باشد، اگر نیازمندی مبهم باشد، اگر حالت‌های مرزی دیده نشده باشند، اگر اولویت‌ها نادرست باشند یا اگر معیار آماده بودن روشن نباشد، خروجی نهایی حتی با کد خوب هم می‌تواند بی‌کیفیت باشد.

مثلاً فرض کنیم در یک فرایند خرید، رفتار سیستم هنگام لغو سفارش بعد از اعمال تخفیف روشن نشده باشد. اگر بعداً کاربر پول اشتباه ببیند یا پشتیبانی درگیر اصلاح دستی شود، شاید ظاهر ماجرا شبیه باگ فنی باشد؛ اما ریشه‌ی آن در تصمیم محصولی مبهم است. تست می‌تواند این ابهام را پیدا کند، اما نمی‌تواند جای تعریف درست رفتار محصول را بگیرد.

اینجاست که نقش مدیر محصول و طراح جدی می‌شود. کیفیت محصولی یعنی تیم بداند دقیقاً چه مسئله‌ای را حل می‌کند، برای چه کسی، با چه سطحی از ریسک، و با چه تعریفی از موفقیت.

گاهی چیزی که در پایان به شکل باگ دیده می‌شود، در واقع ریشه‌ی محصولی دارد. در این حالت، سرزنش توسعه‌دهنده یا QA مسئله را حل نمی‌کند. مشکل از جایی شروع شده که تصمیم محصولی شفاف نبوده است.

نگاه عملیات: کیفیت بعد از merge تمام نمی‌شود​

کیفیت با merge شدن کد تمام نمی‌شود. بخشی از کیفیت تازه بعد از انتشار دیده می‌شود.

آیا سیستم قابل مشاهده است؟ آیا می‌توانیم بفهمیم چه چیزی خراب شده؟ آیا انتشار مرحله‌ای داریم؟ آیا برگشت به نسخه‌ی قبلی آسان است؟ آیا هشدارها معنادارند؟ آیا خطاها به تیمی می‌رسند که می‌تواند آن‌ها را اصلاح کند؟

فرض کنیم کدی که منتشر شده از نظر منطقی درست است، اما بعد از انتشار کندی شدیدی در یک مسیر کاربر ایجاد می‌کند. اگر متریک، لاگ، هشدار و مسیر برگشت امن نداشته باشیم، تیم دیر می‌فهمد، دیر واکنش نشان می‌دهد و کاربر تجربه‌ی بدی می‌گیرد. در این وضعیت، کیفیت فقط به درست بودن کد وابسته نیست؛ به توانایی تیم برای دیدن، فهمیدن و کنترل رفتار سیستم در محیط واقعی هم وابسته است.

یکپارچه‌سازی پیوسته و تحویل پیوسته برای همین مهم‌اند. تغییرات کوچک‌تر، ادغام سریع‌تر، ساخت خودکار و تست خودکار باعث می‌شوند خطاها زودتر دیده شوند و تیم به جای انباشتن ریسک، آن را در جریان کار مدیریت کند.

کیفیت عملیاتی یعنی تیم فقط مسئول ساختن قابلیت نیست؛ مسئول سالم رساندن آن به کاربر و یاد گرفتن از رفتار واقعی سیستم هم هست.

نگاه مدیریتی: کیفیت بدون هزینه ساخته نمی‌شود​

هیچ تیمی فقط با شعار، مالک کیفیت نمی‌شود.

اگر همیشه سرعت ظاهری مهم‌تر از درستی باشد، کیفیت قربانی می‌شود. اگر برای تست، بازبینی، ساده‌سازی، بازپرداخت بدهی فنی و بهبود ابزار زمان وجود نداشته باشد، کیفیت به حرفی زیبا در جلسه‌ها تبدیل می‌شود.

مدیر تیم مسئول ساختن سیستمی است که در آن کیفیت امکان‌پذیر باشد. یعنی زمان، ابزار، اختیار و معیارهای درست فراهم باشد.

معیارها هم رفتار می‌سازند. اگر فقط تعداد قابلیت‌های تحویلی، سرعت بستن تسک یا تاریخ تحویل را بسنجیم، تیم به سمت تحویل سریع‌تر و سطحی‌تر هل داده می‌شود. اما اگر کیفیت بازبینی، نرخ خطا بعد از انتشار، زمان کشف خطا، زمان بازیابی و میزان بازپرداخت بدهی فنی هم دیده شود، پیام مدیریتی فرق می‌کند: کیفیت بخشی از کار است، نه چیزی که بعداً اگر وقت شد به آن برسیم.

اگر تیم برای گفتن «این آماده نیست» امنیت نداشته باشد، دیر یا زود یاد می‌گیرد ریسک را پنهان کند. اگر خطاها با سرزنش پاسخ داده شوند، تیم به جای یادگیری، دفاعی می‌شود.

پس کیفیت فقط مسئولیت افراد نیست؛ محصول سیستم کاری تیم هم هست.

نگاه انسانی: کیفیت با اعتماد ساخته می‌شود​

بحث «مسئول کیفیت کیست؟» فقط بحث فرایند و نقش سازمانی نیست؛ بحث ترس، اعتماد، مالکیت و سرزنش هم هست.

در بسیاری از تیم‌ها، QA به‌مرور تبدیل می‌شود به سپر روانی تیم. توسعه‌دهنده ناخودآگاه فکر می‌کند «اگر مشکلی بود QA می‌گیرد». مدیر محصول خیال می‌کند «اگر نیازمندی مبهم بود، در تست معلوم می‌شود». مدیر تیم هم احساس می‌کند یک مرحله‌ی کنترل آخر مسیر دارد.

این مدل شاید اضطراب تیم را کم کند، اما کیفیت را واقعاً بهتر نمی‌کند. فقط نگرانی را از یک نقش به نقش دیگر منتقل می‌کند.

از طرف دیگر، گفتن اینکه «QA لازم نیست و همه مسئول کیفیت‌اند» هم اگر بدون دقت گفته شود، می‌تواند بی‌رحمانه باشد. تیمی که زمان، ابزار، مهارت و امنیت روانی کافی ندارد، با شعار مالک کیفیت نمی‌شود.

وقتی ضرب‌الاجل سنگین است و فرهنگ تیم سرزنش‌گر است، آدم‌ها کیفیت را قربانی زنده‌ماندن می‌کنند.

کیفیت وقتی ساخته می‌شود که اعضای تیم اجازه داشته باشند درباره‌ی ریسک حرف بزنند، تصمیم‌های عجولانه را نقد کنند، بگویند «این هنوز آماده نیست» و بابت پیدا کردن مشکل تنبیه نشوند.

توسعه‌دهنده بدون زمان و ابزار، مالک کیفیت نمی‌شود. QA بدون احترام، فقط به باگ‌یاب خسته تبدیل می‌شود. مدیر بدون پذیرش هزینه‌ی کیفیت، فقط شعار کیفیت می‌دهد.

پس بالاخره مسئول کیفیت کیست؟​

مسئول کیفیت همه هستند، اما نه به معنای بی‌مالکیتی.

هرکس در نقطه‌ای که تصمیم می‌گیرد و اثر می‌گذارد، مسئول کیفیت همان نقطه است.

مدیر محصول مسئول کیفیت فهم مسئله، اولویت‌ها و تعریف درست آماده بودن است.

توسعه‌دهنده مسئول کیفیت فنی راه‌حل، کد، تست‌پذیری، مدیریت خطا و نگهداشت‌پذیری است.

QA مسئول کمک به کشف ریسک، طراحی سناریوهای مهم و بهتر کردن چرخه‌ی بازخورد است.

عملیات و تیم‌های زیرساخت مسئول قابل اتکا بودن مسیر اجرا، انتشار، مشاهده‌پذیری و بازگشت امن‌اند.

مدیر تیم مسئول ساختن محیطی است که در آن کیفیت فقط شعار نباشد و آدم‌ها برای درست کار کردن، زمان و امنیت داشته باشند.

کیفیت را نقش‌ها به‌تنهایی نمی‌سازند. رابطه‌ی سالم بین نقش‌ها، بازخورد سریع و مالکیت روشن است که کیفیت می‌سازد.

جمع‌بندی​

QA نمی‌تواند کیفیت را بعد از تولید به محصول تزریق کند. تست نهایی نمی‌تواند جای طراحی خوب، کد خوانا، نیازمندی شفاف، انتشار امن و فرهنگ سالم را بگیرد.

کیفیت از همان لحظه‌ای ساخته می‌شود که مسئله تعریف می‌شود، تصمیم گرفته می‌شود، کد نوشته می‌شود، تست طراحی می‌شود و تغییر به دست کاربر می‌رسد.

پس پاسخ دقیق‌تر این است:

کیفیت وقتی ساخته می‌شود که هر نقش، مسئول همان تصمیمی باشد که روی کیفیت اثر می‌گذارد.

برای مطالعه‌ی بیشتر​

• How Google Tests Software - Part One
• Just Say No to More End-to-End Tests
• Software Engineering at Google: Unit Testing
• Practical Test Pyramid
• Continuous Integration
• DORA: Test Automation
• QA as a catalyst for quality-first software development

حرف اصلی این متن ساده است: آن بخش از حافظه‌ی فنی که همراه کد تغییر می‌کند، وقتی قابل اعتماد می‌ماند که در همان مسیری دیده شود که تغییر کد دیده می‌شود؛ کنار کامیت، بازبینی کد، یا سند نسخه‌دار داخل مخزن. باقی مستندها هم باید مسئول مشخص و مخاطب روشن داشته باشند. اگر این شرط‌ها نباشند، مستند به‌جای اینکه فهم سیستم را آسان کند، خودش گیج‌کننده می‌شود.

منظور از مستند بی‌صاحب، سندی است که معلوم نیست چه کسی مسئول درستی امروز آن است، از چه مسیری باید اصلاح شود، و آیا هنوز می‌شود برای تصمیم گرفتن به آن تکیه کرد یا نه.

پس بحث اصلی این نیست که مستند کجا راحت‌تر نوشته می‌شود؛ بحث این است که کجا درست‌تر می‌ماند. سندی که سریع نوشته می‌شود اما همراه تغییرهای واقعی دیده نمی‌شود، دیر یا زود از واقعیت عقب می‌افتد.

در بسیاری از تیم‌ها، بخشی از دانش فنی در جای نامناسب زندگی می‌کند: دلیل یک تنظیم در ذهن یک نفر است، رفتار حساس یک سرویس در کد هست اما توضیحش نیست، و تصمیم‌های قدیمی در صفحه‌هایی مانده‌اند که معلوم نیست هنوز معتبرند یا نه. مسئله فقط کمبود مستند نیست؛ مسئله این است که حافظه‌ی تیم پراکنده، بی‌مسئول و جدا از کار روزمره‌ی توسعه است.

این نوشته از همین نقطه شروع می‌کند: کد چه چیزی را می‌گوید، مستند چه چیزی را باید بگوید، و هر نوع دانش فنی کجا باید بماند تا با تغییر سیستم از واقعیت عقب نیفتد.

حافظه‌ی شفاهی با رشد تیم دوام نمی‌آورد​

در تیم کوچک، پرسیدن از آدم‌ها سریع‌تر از خواندن سند است. یکی می‌داند سرویس چطور بالا می‌آید، یکی دلیل یک رفتار عجیب را یادش هست، یکی می‌داند کدام تنظیم حساس است. این مدل تا وقتی کار می‌کند که تیم کوچک، پایدار و نزدیک باشد.

اما با رشد تیم، همین الگو تبدیل به ریسک می‌شود. نفر جدید برای یک تغییر ساده باید چند نفر را پیدا کند. کسی که دلیل تصمیم را می‌دانست جابه‌جا شده. کد تغییر کرده، اما توضیح تصمیم نه. نتیجه این است که تغییرهای آینده نه بر پایه‌ی فهم مشترک، بلکه بر پایه‌ی حدس انجام می‌شوند.

مثال ساده‌اش تنظیمی است که همه می‌دانند نباید تغییر کند، اما هیچ‌جا نوشته نشده چرا. چند ماه بعد، یک نفر با نیت ساده‌سازی آن مقدار را عوض می‌کند و تازه معلوم می‌شود آن تنظیم عجیب سپر یک سازگاری قدیمی بوده است. مشکل از آدمی که تغییر داده نیست؛ مشکل از حافظه‌ای است که به او منتقل نشده است.

پس مسئله فقط نوشتن چند صفحه‌ی بیشتر نیست؛ مسئله تبدیل دانش فردی به حافظه‌ای است که تیم بتواند به آن تکیه کند.

معیار مستند خوب: کاهش هزینه‌ی فهم و تغییر​

مستند فنی برای رسمی‌تر شدن پروژه نیست. معیار خوب بودن آن این است که هزینه‌ی فهم، استفاده، تغییر و نگهداشت سیستم را کم کند. اگر مستند این هزینه را کم نکند، حتی اگر کامل و مرتب به نظر برسد، ارزش مهندسی کمی دارد.

از این زاویه، مستند خوب چهار کار می‌کند: قراردادها را روشن می‌کند، دلیل تصمیم‌ها را نگه می‌دارد، مسیر شروع را کوتاه می‌کند، و خطاهای تکراری را کم می‌کند. سود آن هم معمولاً بعداً دیده می‌شود؛ نویسنده امروز وقت می‌گذارد، اما خواننده‌ی آینده از حدس و پرس‌وجوی دوباره بی‌نیاز می‌شود.

این سود فقط برای خواننده نیست. نوشتن مستند، خود طراحی را هم آزمون می‌کند. اگر نتوانیم قرارداد یک تابع، رفتار یک سرویس یا دلیل یک تصمیم را روشن توضیح دهیم، شاید مشکل فقط در بیان نیست؛ شاید خود طراحی هنوز مبهم است.

مسئول محتوای فنی باید تیم مهندسی باشد؛ چون زمینه‌ی تصمیم، محدودیت‌های پیاده‌سازی و خطرهای تغییر را بهتر از هر نقش بیرونی می‌شناسد. البته این به معنای نثر شلوغ و سلیقه‌ای نیست، و کمک گرفتن از نویسنده‌ی فنی یا ویراستار می‌تواند کیفیت متن را بهتر کند. مستند هم مثل کد به سبک مشترک نیاز دارد: زبان یکدست، قالب ثابت، واژه‌های روشن، و متن کوتاهی که بتوان سریع مرورش کرد. کامل بودن سند کافی نیست؛ سندی که پیدا کردن جواب را سخت کند، هنوز کارش را خوب انجام نداده است.

پس مستند خوب فقط «درست» نیست؛ باید پیدا شود، سریع خوانده شود، و خواننده را به تصمیم درست برساند.

چرا مستندها از واقعیت عقب می‌افتند؟​

مستند معمولاً به دو دلیل خراب می‌شود: یا از جایی که تغییر رخ می‌دهد دور است، یا مسئول و مسیر بازبینی ندارد. در هر دو حالت، سند یک روز درست بوده، اما تضمینی برای درست ماندنش وجود ندارد.

ویکی و ابزارهایی مثل Confluence در شروع کار جذاب‌اند: نوشتن در آن‌ها سریع است، لینک دادن آسان است و همه می‌توانند چیزی اضافه کنند. این مزیت مهمی است. ویکی برای دانش بین‌تیمی، تصمیم‌های سازمانی، پرسش‌های پرتکرار، مسیرهای شروع و لینک دادن به سندهای معتبر جای خوبی است.

اما ویکی بهتر است نقشه‌ی راه و فهرست منابع قابل اتکا باشد، نه اینکه خودش همه‌ی آن منابع را دوباره بازنویسی کند. مثلاً صفحه‌ی ویکی می‌تواند بگوید راهنمای اجرای سرویس کجاست، سند طراحی کدام است، و قرارداد API از کجا تولید می‌شود. اگر خودش همان دستورهای اجرا و همان قراردادها را جداگانه نگه دارد، از همان لحظه خطر دو مرجع ناسازگار شروع می‌شود.

مشکل اصلی از جایی شروع می‌شود که دانشی که همراه کد عوض می‌شود فقط در ویکی بماند. کد در مخزن تغییر می‌کند، پیکربندی عوض می‌شود، رابط برنامه‌نویسی شکل تازه‌ای می‌گیرد، اما صفحه‌ی بیرون از این چرخه همان‌طور باقی می‌ماند. این عقب‌افتادن معمولاً از بی‌دقتی یک نفر نمی‌آید؛ از جدا بودن مسیر تغییر کد و مسیر تغییر سند می‌آید.

مثلاً دستور اجرای محلی سرویس در ویکی مانده، اما فایل‌های داخل مخزن عوض شده‌اند. نفر تازه‌وارد طبق ویکی جلو می‌رود، خطا می‌گیرد، از چند نفر می‌پرسد، و در پایان می‌فهمد دستور درست در README مخزن بوده است. این فقط اتلاف وقت نیست؛ یعنی تیم دو روایت از یک واقعیت ساخته است.

در سازمان‌های بزرگ، این وضعیت معمولاً به چند نسخه از یک واقعیت ختم می‌شود: چند راهنما برای یک کار، چند توضیح برای یک رفتار، و چند صفحه که معلوم نیست کدام هنوز معتبر است. راه‌حل این نیست که سند بیشتری بنویسیم؛ باید یکی منبع قابل اتکا باشد و بقیه حذف، ادغام یا صریحاً قدیمی اعلام شوند.

خرابی مستند هم باید مثل خرابی محصول دیده شود. اگر راهنمای اجرا غلط است، اگر مثال دیگر کار نمی‌کند، یا اگر صفحه‌ای خواننده را به مسیر اشتباه می‌برد، این یک مسئله‌ی واقعی در نگهداشت سیستم است؛ باید ثبت شود، مسئول داشته باشد و تا اصلاح کامل رها نشود.

پس بحث، حمله به ویکی نیست. بحث تقسیم درست مسئولیت است: ویکی می‌تواند نقشه و درگاه ورود باشد؛ اما رفتاری که با کد عوض می‌شود باید جایی بماند که هنگام تغییر کد دیده و بازبینی شود.

کد چه می‌گوید، مستند چه باید بگوید؟​

عبارت «کد خودش مستند است» اگر به معنای خوانا بودن کد باشد، درست است. اما اگر نتیجه بگیریم که دیگر نیازی به توضیح نداریم، خطاست. کد معمولاً نشان می‌دهد سیستم چه می‌کند؛ ولی همیشه نمی‌گوید چرا این راه انتخاب شده، کجا نباید تغییر کند، و چه محدودیتی پشت یک رفتار ظاهراً عجیب وجود دارد.

کامنت بد چیزی را تکرار می‌کند که از خود کد پیداست:

# Check if the error code is final.
if error_code in FINAL_ERROR_CODES:
    return False

کامنت خوب، زمینه‌ای را ثبت می‌کند که برای تغییر امن لازم است:

# These errors are final for the old payment provider.
# Retrying them can create duplicate settlement records.
if error_code in FINAL_ERROR_CODES:
    return False

نتیجه این نیست که هر خط کد باید توضیح داشته باشد. نتیجه این است که هر دانشی که برای تغییر امن لازم است و از خود کد روشن نیست، باید ثبت شود.

حافظه‌ی فنی چه شکل‌هایی دارد؟​

مستند یک چیز واحد نیست. بخشی از حافظه‌ی فنی در کامنت تابع و قرارداد API می‌ماند، بخشی در README و راهنمای راه‌اندازی، بخشی در سند طراحی، و بخشی در صفحه‌ی شروع یا ویکی. خطا از جایی شروع می‌شود که همه‌ی این‌ها را در یک ظرف بریزیم.

اول باید مخاطب روشن باشد. استفاده‌کننده‌ی API دنبال قرارداد استفاده است. نگه‌دارنده دنبال دلیل پیاده‌سازی و نقاط خطر است. تازه‌وارد مسیر شروع می‌خواهد. تصمیم‌گیر فنی دنبال گزینه‌های ردشده و هزینه‌های هر انتخاب است.

از زاویه‌ی رفتار خواننده هم دو حالت مهم داریم. گاهی خواننده جست‌وجوگر است؛ سؤال مشخصی دارد و جواب سریع و دقیق می‌خواهد. گاهی رهگذر است؛ تازه با سیستم روبه‌رو شده و هنوز نمی‌داند باید دنبال چه چیزی بگردد. مستند مرجع برای اولی خوب است، صفحه‌ی شروع و آموزش گام‌به‌گام برای دومی.

بعد از مخاطب، نوع مستند مهم است. مرجع، آموزش، سند طراحی، توضیح مفهومی و صفحه‌ی شروع هرکدام کار جدا دارند. سندی که هم‌زمان می‌خواهد همه‌ی این کارها را انجام دهد، معمولاً هیچ‌کدام را خوب انجام نمی‌دهد.

مرجع API بهتر است تا حد ممکن از نزدیک‌ترین جای معتبر ساخته شود؛ مثلاً از کامنت و قرارداد کنار خود کد. اگر همان قرارداد را یک‌بار کنار کد و یک‌بار دستی در ویکی بنویسیم، از همان لحظه دو جای بالقوه برای اختلاف ساخته‌ایم.

سند مفهومی کار دیگری دارد. قرار نیست همه‌ی حالت‌ها را پوشش دهد؛ کارش ساختن فهم مشترک است. مرجع باید دقیق و قابل جست‌وجو باشد، سند مفهومی باید خواننده را به فهم کلی برساند. اگر این دو را قاطی کنیم، هم مرجع کند می‌شود، هم توضیح مفهومی سنگین.

صفحه‌ی شروع هم نباید انبار محتوا شود. کارش این است که خواننده را به مسیر درست بفرستد: این‌جا شروع کن، برای مرجع این را ببین، برای طراحی آن را بخوان، برای راه‌اندازی از این راهنما برو. اگر خودش تبدیل به ترکیبی از آموزش، مرجع، تاریخچه و لینک‌های پراکنده شود، دیگر صفحه‌ی شروع نیست؛ یک ویکی کوچک و گیج‌کننده است.

سند طراحی باید پیش از کدنویسی به تیم کمک کند تصمیم را بررسی کند، نه اینکه فقط بعد از پیاده‌سازی گزارش تصمیم باشد. مسئله، هدف و غیرهدف، راه‌حل پیشنهادی، گزینه‌های ردشده، هزینه‌های هر انتخاب، نگرانی‌های امنیتی و عملیاتی، و مسیر جابه‌جایی از وضعیت قدیم به وضعیت جدید باید قبل از شروع کار روشن شوند.

آموزش گام‌به‌گام باید برعکس عمل کند: خواننده را با کمترین حاشیه از صفر به یک نتیجه‌ی واقعی برساند؛ مثل اجرای سرویس، ساخت اولین درخواست یا نوشتن اولین تست. پیش‌نیازها باید معلوم باشند، گام‌ها از چشم خواننده شماره بخورند، و در هر گام خروجی مورد انتظار روشن باشد.

کامنت نزدیک‌ترین بخش حافظه‌ی فنی به کد است. کامنت سطح فایل باید نقش فایل را بگوید. کامنت کلاس باید مسئولیت و رابطه‌ی آن را روشن کند. کامنت تابع باید قرارداد رفتاری را توضیح دهد، نه اینکه نام تابع را تکرار کند. اگر توضیح دادن یک API سخت و طولانی است، شاید مشکل فقط در مستند نیست؛ شاید خود API بیش از حد پیچیده طراحی شده است.

پس شکل مستند را نباید از روی سلیقه انتخاب کرد. باید دید خواننده دنبال چیست و آن دانش با چه چیزی تغییر می‌کند.

وقتی خواننده فقط انسان نیست​

امروز بخشی از خواندن کد و مستند را ابزارهای مبتنی بر مدل زبانی بزرگ (LLM) انجام می‌دهند: برای توضیح کد، تولید تست، بازبینی و بازنویسی. این ابزارها وقتی زمینه‌ی درست ندارند، همان محدودیت انسان را دارند؛ مسیر اجرا را می‌بینند، اما دلیل تصمیم را نمی‌فهمند.

LLM جای مستند را نمی‌گیرد؛ نبود مستند خوب را پرهزینه‌تر و آشکارتر می‌کند. پس مستند نزدیک به کد فقط برای آدم‌ها نیست. زمینه‌ای است که کیفیت فهم ابزارها را هم بالا می‌برد و احتمال پیشنهادهای ظاهراً منطقی اما نادرست را کم می‌کند.

حافظه‌ی فنی چطور زنده می‌ماند؟​

مستند مهم، مثل کد، باید نگه داشته شود. یعنی مسئول داشته باشد، در تغییرهای مرتبط دیده شود، نسخه بخورد، بازبینی شود و وقتی قدیمی شد، یا به‌روز شود یا روشن کنار گذاشته شود.

بازبینی مستند فقط غلط‌گیری نگارشی نیست. باید سه زاویه را جدا دید: درستی فنی، وضوح برای مخاطب، و کیفیت نوشتار. بازبینی فنی می‌پرسد آیا سند واقعیت سیستم را درست می‌گوید؟ بازبینی مخاطب می‌پرسد آیا خواننده‌ی هدف با این متن به جواب می‌رسد؟ بازبینی نوشتاری می‌پرسد آیا متن روشن، منسجم و بی‌ابهام است؟

برای هر سند فنی مهم باید بتوانیم به چند پرسش ساده جواب بدهیم: این سند کجا منبع قابل اتکا دارد؟ چه کسی مسئول آن است؟ آخرین بار کی و همراه با چه تغییری به‌روز شده؟ اگر غلط بود، از چه مسیری اصلاح می‌شود؟ اگر دیگر معتبر نیست، آیا این را صریح گفته‌ایم؟

این حافظه کجا باید زندگی کند؟​

حرف اصلی این نیست که همه‌چیز باید کنار کد باشد و هر ابزار دیگری بی‌ارزش است. حرف دقیق‌تر این است: هر دانش باید جایی زندگی کند که هم خواننده‌ی درست آن را پیدا کند، هم تغییر درست بتواند آن را به‌روز نگه دارد.

اینجا باید بین سه جایگاه فرق بگذاریم. کنار کد یعنی کامنت تابع، توضیح رفتار حساس و قرارداد نزدیک به پیاده‌سازی. داخل مخزن یعنی README، پوشه‌ی docs، راه‌اندازی، تست، ساخت، انتشار و سند طراحی نسخه‌دار. ویکی یا Confluence یعنی دانش بین‌تیمی، سیاست‌ها، گزارش‌ها و مسیرهای شروع که کمتر با تغییر مستقیم کد عوض می‌شوند.

پس سؤال درست این نیست که از چه ابزاری استفاده کنیم؟ سؤال درست این است: این دانش با چه چیزی تغییر می‌کند و خواننده کجا دنبالش می‌گردد؟ جواب این دو پرسش معمولاً جای درست سند را نشان می‌دهد.

جمع‌بندی: حافظه‌ی فنی باید زنده بماند​

هدف مستند، زیاد کردن متن نیست؛ ساختن حافظه‌ای است که تیم بتواند به آن اعتماد کند. حافظه‌ای که فقط در ذهن آدم‌ها باشد، با رفتن آدم‌ها کم‌رنگ می‌شود. حافظه‌ای که فقط در ویکی دور از کد باشد، با تغییر سیستم عقب می‌افتد. حافظه‌ای که کنار کد، داخل مخزن، کنار تصمیم و در مسیر تغییر باشد، شانس زنده ماندن دارد.

کد حقیقت اجرای سیستم را نشان می‌دهد، اما همه‌ی حقیقت مهندسی را نه. دلیل تصمیم‌ها، قراردادهای پنهان، محدودیت‌های تاریخی، مخاطب مستند و جای درست هر دانشی باید جایی نوشته شود که هم پیدا شود و هم به‌روز بماند.

حافظه‌ی فنی زنده با متن زیاد ساخته نمی‌شود؛ با منبع قابل اتکا، مسئول مشخص، و نگهداشت پیوسته ساخته می‌شود. پس مسئله این نیست که مستند داشته باشیم یا نه. مسئله این است که مستندمان بخشی از کار مهندسی باشد، نه کاری تزئینی پس از آن. اگر مستند کنار مسیر واقعی تغییر بماند، به حافظه‌ی فنی تیم تبدیل می‌شود؛ اگر جدا بماند، دیر یا زود فقط بایگانی محترمانه‌ای از حدس‌ها خواهد بود.

من در این نوشته نمی‌خواهم از همان ابتدا سراغ معماری‌های پرزرق‌وبرق بروم و برای هر مسئله‌ای یک ابزار بزرگ روی میز بگذارم. برعکس، می‌خواهم از یک سؤال ساده شروع کنم: اگر واقعاً بخواهیم محصولی را قدم‌به‌قدم بسازیم، چه زمانی به چه چیزی نیاز پیدا می‌کنیم؟ چه زمانی یک برنامه‌ی ساده کافی است؟ چه زمانی همان سادگی، دیگر کمک نمی‌کند و تبدیل به مانع می‌شود؟ چرا روزی به طراحی بهتر رابط‌های برنامه‌نویسی فکر می‌کنیم، روزی به صف پیام، روزی به کانتینر، روزی به مهاجرت داده، و روزی به عملیات یادگیری ماشین؟

این نوشته سفری مرحله‌به‌مرحله در مسیر بزرگ‌شدن یک نرم‌افزار است؛ از روزی که فقط می‌خواهیم چیزی کار کند، تا روزی که باید قابل تغییر، قابل اعتماد و قابل نگه‌داری هم بماند. قرار نیست با واژه‌ها مرعوب شویم؛ قرار است بفهمیم هرکدام کجا به درد می‌خورند و چرا نباید زودتر از موعد سراغشان برویم. خط اصلی این مسیر برای من همین است: نه معماری نمایشی، نه سادگی بی‌مسئولیت.

وقتی یک تغییر کوچک، چند جای سیستم را می‌شکند​

گاهی ماجرا از یک تغییر خیلی کوچک آغاز می‌شود. مثلاً در پاسخ سرور، نام یک فیلد را عوض می‌کنیم؛ چون در کد تازه، نام جدید تمیزتر و دقیق‌تر به نظر می‌رسد. روی نسخه‌ی وب همه‌چیز درست کار می‌کند. چند بار هم دستی امتحان می‌کنیم و مشکلی نمی‌بینیم. با خودمان می‌گوییم: «چیزی نبود، فقط اسم یک فیلد عوض شد.»

اما چند ساعت بعد پیام‌ها شروع می‌شوند. برنامه‌ی موبایل قیمت محصول را نشان نمی‌دهد. پنل مدیریت در بارگذاری داده‌ها خطا می‌دهد. شاید یک گزارش داخلی هم از همان پاسخ استفاده می‌کرده و حالا خالی مانده است. ناگهان روشن می‌شود چیزی که برای ما «یک تغییر کوچک» بود، برای چند بخش دیگر از سیستم، شکستن یک قول و قرار بوده است.

اینجاست که API یا همان رابط برنامه‌نویسی، از یک جزئیات فنی ساده به یک قرارداد تبدیل می‌شود. تا وقتی فقط خودمان از آن استفاده می‌کنیم، شاید چند مسیر و چند پاسخ ساده به نظر برسد. اما وقتی وب، موبایل، پنل مدیریت، یک تیم دیگر یا یک سرویس بیرونی به آن وابسته می‌شوند، دیگر با یک تکه کد معمولی طرف نیستیم. داریم زبانی مشترک می‌سازیم که دیگران بر پایه‌ی آن کارشان را جلو می‌برند.

رویکرد API-first را می‌شود خیلی ساده این‌طور فهمید: اول قرارداد را روشن کنیم، بعد سراغ پیاده‌سازی برویم. یعنی پیش از اینکه با عجله کد بزنیم، کمی مکث کنیم و بپرسیم این بخش از سیستم قرار است با چه کسانی حرف بزند. چه داده‌ای لازم است؟ نام‌ها برای مصرف‌کننده قابل فهم‌اند؟ خطاها چطور برمی‌گردند؟ اگر چیزی تغییر کرد، تکلیف نسخه‌های قبلی چه می‌شود؟ پاسخ امروز فقط نیاز همین صفحه را حل می‌کند، یا برای رشد آرام فردا هم جایی می‌گذارد؟

یک تغییر کوچک در پاسخ سرور، وقتی چند مصرف‌کننده دارد، دیگر فقط یک تغییر کوچک نیست.

اینجا بحث سازگاری هم مهم می‌شود. منظور از سازگاری پسرو (Backward Compatibility) این است که نسخه‌های قدیمی‌ترِ مصرف‌کننده‌ها بعد از تغییر API همچنان کار کنند. مثلاً اگر فیلد price را ناگهان حذف کنیم و فقط unit_price را نگه داریم، برنامه‌ی موبایلی که هنوز به‌روزرسانی نشده ممکن است قیمت را گم کند. راه سنجیده‌تر این است که برای مدتی هر دو فیلد را برگردانیم، مصرف‌کننده‌ها را به نام تازه کوچ بدهیم، و بعد از گذر زمان و با اطمینان، فیلد قدیمی را حذف کنیم.

سازگاری پیشرو (Forward Compatibility) از زاویه‌ی دیگری به همین مسئله نگاه می‌کند: آیا مصرف‌کننده‌های امروز می‌توانند با پاسخ‌های کمی تازه‌تر کنار بیایند؟ مثلاً اگر سرور یک فیلد جدید به پاسخ اضافه کرد، آیا برنامه‌ی موبایل فقط آن را نادیده می‌گیرد یا چون چیزی را نمی‌شناسد، خطا می‌دهد؟ API خوب معمولاً به مصرف‌کننده‌ها یاد می‌دهد در برابر چیزهای تازه‌ای که به قرارداد افزوده می‌شوند، شکننده نباشند.

در تغییرهای امن‌تر، اول چیز تازه را اضافه می‌کنیم، سپس مصرف‌کننده‌ها را آرام‌آرام کوچ می‌دهیم، و در پایان نسخه‌ی قدیمی را بازنشسته می‌کنیم.

البته این نگاه به معنی سنگین کردن کار از روز اول نیست. قرار نیست محصولی را که هنوز شکل نگرفته، زیر بار سندهای طولانی، جلسه‌های زیاد و طراحی‌های خشک ببریم. گاهی یک قرارداد کوتاه، چند نمونه‌ی روشن از درخواست و پاسخ، نام‌گذاری دقیق، و توافق ساده میان اعضای تیم کافی است. مسئله این نیست که همه‌چیز را بزرگ و تشریفاتی کنیم؛ مسئله این است که بفهمیم کجا داریم چیزی می‌سازیم که دیگران روی آن حساب می‌کنند.

برای من، درس این بخش همین است: هنوز قرار نیست معماری بزرگی بسازیم، اما باید بفهمیم بعضی چیزها زودتر از بقیه به مرز سیستم تبدیل می‌شوند. API یکی از همان جاهاست؛ جایی که تصمیم‌های کوچک امروز، روی آزادی عمل فردای ما اثر می‌گذارند.

وقتی یک پاسخ واحد، برای همه مناسب نیست​

اوایل کار، معمولاً یک API عمومی برای همه کافی است. نسخه‌ی وب همان داده‌ای را می‌گیرد که لازم دارد، صفحه‌ها را می‌سازد، و کاربر هم بدون دردسر با محصول کار می‌کند. تا وقتی فقط یک نما داریم، این مدل ساده و قابل فهم است. حتی اگر کمی داده‌ی اضافه هم در پاسخ‌ها باشد، هنوز مسئله‌ی بزرگی به نظر نمی‌رسد.

اما محصول که جلوتر می‌رود، نماها هم شبیه هم نمی‌مانند. برنامه‌ی موبایل می‌خواهد پاسخ‌ها سبک‌تر باشند، چون صفحه کوچک‌تر است و شبکه همیشه پایدار نیست. نسخه‌ی وب شاید به داده‌های بیشتری برای ساختن یک صفحه‌ی کامل نیاز داشته باشد. پنل مدیریت هم اصلاً جنس دیگری از اطلاعات می‌خواهد؛ جزئیات بیشتر، وضعیت‌های داخلی، ابزارهای جست‌وجو، و داده‌هایی که نباید در دسترس کاربر عادی باشد.

اینجاست که یک API عمومی کم‌کم زیر فشار قرار می‌گیرد. اگر بخواهیم همه را با همان پاسخ واحد راضی کنیم، یا پاسخ‌ها بیش از حد بزرگ و شلوغ می‌شوند، یا هر نما مجبور می‌شود خودش چندین درخواست بزند و داده‌ها را کنار هم بچیند. نتیجه معمولاً این است: بخشی از پیچیدگی بک‌اند، آرام‌آرام به سمت فرانت‌اند هل داده می‌شود.

بک‌اند ویژه‌ی نما یا Backend for Frontend، که معمولاً به اختصار BFF گفته می‌شود، پاسخی به همین وضعیت است. ایده‌اش این است که به‌جای ساختن یک API عمومی که قرار است همه‌ی نماها را راضی کند، برای هر تجربه‌ی کاربری مهم، یک لایه‌ی بک‌اند نزدیک‌تر به همان نما بسازیم. این لایه می‌تواند داده‌ها را از چند سرویس یا چند API بگیرد، آن‌ها را به شکل مناسب کنار هم بگذارد، چیزهای اضافه را حذف کند، و پاسخی برگرداند که دقیقاً به درد همان نما بخورد.

مثلاً برنامه‌ی موبایل شاید برای صفحه‌ی سفارش فقط نام محصول، قیمت، وضعیت ارسال و یک دکمه‌ی اقدام لازم داشته باشد. اما پنل مدیریت برای همان سفارش، شناسه‌های داخلی، وضعیت پرداخت، تاریخچه‌ی تغییرات، یادداشت پشتیبانی و چند فیلتر دیگر می‌خواهد. اگر هر دو را با یک پاسخ واحد تغذیه کنیم، یا موبایل داده‌ی زیادی می‌گیرد، یا پنل مدیریت داده‌ی کمی. BFF کمک می‌کند هرکدام چیزی را بگیرند که برای تجربه‌ی خودشان مناسب‌تر است.

در این تصویر، اصل مسئله دیده می‌شود: وقتی نیاز نماها از هم فاصله می‌گیرد، یک پاسخ عمومی ممکن است همه را کمی ناراضی کند؛ اما BFF می‌تواند پاسخ هر نما را به شکل مناسب خودش آماده کند.

البته اینجا هم همان قاعده‌ی همیشگی برقرار است: نباید زودتر از درد واقعی، درمان پیچیده بیاوریم. اگر محصول کوچک است، فقط یک کلاینت دارد، یا تفاوت نیازها هنوز جدی نشده، ساختن چند لایه‌ی BFF بیشتر از اینکه کمک کند، نگه‌داری را سخت می‌کند. هر لایه‌ی تازه یعنی کد تازه، خطای تازه، آزمون تازه، مالکیت تازه و هماهنگی تازه.

برای من، BFF یعنی احترام گذاشتن به این واقعیت که همه‌ی مصرف‌کننده‌ها یکسان نیستند. وب، موبایل و پنل مدیریت شاید از یک محصول حرف بزنند، اما تجربه‌ی یکسانی نمی‌سازند. پس گاهی لازم است بک‌اند هم به‌جای یک پاسخ عمومی برای همه، پاسخ‌هایی نزدیک‌تر به نیاز هر نما فراهم کند؛ البته فقط وقتی این تفاوت واقعاً به اندازه‌ی کافی جدی شده باشد.

وقتی ورودی سیستم شلوغ می‌شود و سرویس‌ها هم با هم حرف دارند​

تا اینجا محصول چند نمای متفاوت پیدا کرده است: وب، موبایل و پنل مدیریت. هرکدام هم نیاز خودش را دارد و کم‌کم مسیرهای بیشتری به بک‌اند باز شده‌اند. اول شاید همه‌چیز ساده به نظر برسد؛ چند درخواست از بیرون می‌آید و چند پاسخ برمی‌گردد. اما بعد از مدتی سؤال‌های تازه‌ای پیدا می‌شوند: چه کسی حق دارد وارد سیستم شود؟ اگر یک کاربر یا یک ربات بیش از اندازه درخواست فرستاد چه کنیم؟ درخواست‌ها را کجا ثبت و ردیابی کنیم؟ نسخه‌های مختلف API را چطور مدیریت کنیم؟

اگر برای هر سرویس جداگانه همین منطق‌ها را بنویسیم، خیلی زود با تکرار و آشفتگی روبه‌رو می‌شویم. یک سرویس احراز هویت را یک‌جور انجام می‌دهد، سرویس دیگر محدودسازی درخواست را جور دیگری پیاده می‌کند، و لاگ‌ها هم هرکدام شکل خودشان را دارند. نتیجه این می‌شود که ورودی سیستم به جای یک مسیر قابل فهم، تبدیل می‌شود به چند در کوچک و پراکنده که هرکدام قانون خودش را دارد.

وقتی هر نما مستقیم به چند مسیر و سرویس وصل می‌شود، کنترل ورودی‌ها سخت‌تر و پراکنده‌تر می‌شود.

اینجاست که API Gateway معنا پیدا می‌کند. Gateway را می‌توان مثل در ورودی آگاهانه‌ی سیستم دید؛ جایی که درخواست‌های بیرونی از آن عبور می‌کنند و بعد به سرویس مناسب می‌رسند. این لایه می‌تواند بخشی از کارهای مشترک را متمرکزتر کند: احراز هویت، محدودسازی نرخ درخواست، مسیریابی، ثبت لاگ، کنترل دسترسی و گاهی تبدیل شکل درخواست یا پاسخ.

در این مدل، درخواست‌های بیرونی اول از یک نقطه‌ی مشخص عبور می‌کنند و بعد به سرویس مناسب می‌رسند.

اینجا ممکن است یک سؤال طبیعی پیش بیاید: مگر در بخش قبل نگفتیم BFF هم بین فرانت‌اند و بک‌اند می‌نشیند؟ پس Gateway چه فرقی با BFF دارد؟ فرق اصلی در نیت و مسئولیت آن‌هاست. BFF نزدیک به تجربه‌ی کاربری است و می‌پرسد «این نما دقیقاً چه داده‌ای و با چه شکلی لازم دارد؟» اما Gateway نزدیک به مرز ورودی سیستم است و می‌پرسد «این درخواست اصلاً اجازه‌ی ورود دارد؟ به کدام سرویس باید برود؟ چطور محدود، ثبت و ردیابی شود؟»

اما این تمرکز یک دام هم دارد. هرچه چیزهای بیشتری را از یک نقطه عبور می‌دهیم، باید بیشتر مراقب باشیم همان نقطه به گلوگاه یا محل خوابیدن کل سیستم تبدیل نشود. Gateway قرار نیست یک سرور تنها و قهرمان باشد که اگر از کار افتاد، همه‌ی مسیرهای ورود به سیستم هم از کار بیفتند. Gateway یک نقش معماری است، نه الزاماً یک نمونه‌ی منفرد.

داستان همین‌جا تمام نمی‌شود. فرض کنیم محصول بزرگ‌تر شده و دیگر پشت صحنه فقط یک بک‌اند ساده نداریم. سرویس سفارش با سرویس پرداخت حرف می‌زند، پرداخت با کیف پول، سفارش با اعلان، و گزارش‌گیری با چند بخش دیگر. حالا مسئله فقط «ورود درخواست از بیرون» نیست؛ مسئله‌ی تازه این است که سرویس‌های داخلی چگونه با هم حرف بزنند.

اینجا سؤال‌ها عوض می‌شوند. اگر سرویس سفارش کند شد، از کجا بفهمیم مشکل از خودش بوده یا از پرداخت؟ اگر ارتباط بین دو سرویس شکست، تکرار درخواست چگونه انجام شود؟ ارتباط داخلی سرویس‌ها امن است؟ اگر بخواهیم فقط بخشی از ترافیک را به نسخه‌ی تازه‌ی یک سرویس بفرستیم، این کار کجا مدیریت شود؟ آیا همه‌ی این منطق‌ها باید در کد تک‌تک سرویس‌ها تکرار شوند؟

Service Mesh برای چنین مسئله‌ای مطرح می‌شود. اگر API Gateway بیشتر به در ورودی شهر شبیه باشد، Service Mesh بیشتر شبیه شبکه‌ی خیابان‌ها و چراغ‌ها و تابلوهایی است که رفت‌وآمد درون شهر را قابل کنترل و قابل مشاهده می‌کند. این لایه روی ارتباط میان سرویس‌های داخلی تمرکز دارد: ردیابی درخواست‌ها، کنترل ترافیک، امنیت ارتباط سرویس به سرویس، سیاست‌های تکرار درخواست، و مشاهده‌پذیری بهتر.

اگر Gateway ورودی سیستم را سامان می‌دهد، Service Mesh گفت‌وگوی درونی سرویس‌ها را قابل مشاهده‌تر و قابل کنترل‌تر می‌کند.

برای ساده‌تر شدن تفاوت این سه، می‌شود این‌طور نگاه کرد:

برای من، تفاوت اصلی این سه در محل درد است. اگر درد ما در تفاوت نیاز نماهاست، BFF می‌تواند کمک کند. اگر درد ما در ورودی سیستم است، یعنی کلاینت‌ها زیاد شده‌اند، احراز هویت و مسیریابی و کنترل درخواست‌ها پراکنده شده، Gateway قابل بررسی است. اگر درد ما در درون سیستم است، یعنی سرویس‌ها زیاد شده‌اند و گفت‌وگوی میان آن‌ها سخت، کند یا نامرئی شده، آن وقت Service Mesh معنا پیدا می‌کند.

پس باز هم همان قاعده‌ی کلی تکرار می‌شود: ابزار را از روی اسمش انتخاب نکنیم؛ از روی دردی انتخاب کنیم که واقعاً در سیستم پیدا شده است.

وقتی زبان کسب‌وکار در کد گم می‌شود​

اوایل کار، ثبت سفارش شاید خیلی ساده به نظر برسد. کاربر چیزی را انتخاب می‌کند، پرداخت انجام می‌شود، سفارش ثبت می‌شود و تمام. در چنین مرحله‌ای، چند تابع ساده و چند مسیر روشن شاید کاملاً کافی باشند. هنوز نه وضعیت‌های زیادی داریم، نه قانون‌های ریز و درشت، نه استثناهایی که هر هفته تغییر کنند.

اما محصول که رشد می‌کند، سفارش دیگر فقط «سفارش» نیست. تخفیف اضافه می‌شود، لغو سفارش می‌آید، بازپرداخت مطرح می‌شود، موجودی باید کنترل شود، وضعیت پرداخت اهمیت پیدا می‌کند، پشتیبانی می‌خواهد بعضی چیزها را دستی تغییر دهد، و برای هرکدام هم چند قاعده‌ی کوچک اما مهم داریم. کم‌کم می‌بینیم چیزی که در ظاهر یک قابلیت ساده بود، در عمل تبدیل شده به مجموعه‌ای از تصمیم‌های کسب‌وکاری.

مشکل از جایی شروع می‌شود که این تصمیم‌ها در کد پخش می‌شوند. کمی از منطق سفارش در کنترلر است، کمی در مدل پایگاه داده، کمی در سرویس پرداخت، کمی در پنل مدیریت، و کمی هم در یک تابع کمکی قدیمی که معلوم نیست دقیقاً چرا نوشته شده است. حالا اگر بخواهیم یک قانون کوچک را تغییر دهیم، باید چند جا را بگردیم و امیدوار باشیم چیزی از قلم نیفتاده باشد.

در این وضعیت، مشکل فقط زیاد شدن کد نیست؛ مشکل این است که زبان کسب‌وکار در میان جزئیات فنی گم شده است.

اینجاست که طراحی دامنه‌محور یا Domain Driven Design، که معمولاً DDD گفته می‌شود، معنا پیدا می‌کند. من DDD را پیش از آنکه یک مجموعه اصطلاح یا الگوی پیاده‌سازی بدانم، تلاشی برای جدی گرفتن زبان مسئله می‌فهمم. یعنی اگر در کسب‌وکار ما مفاهیمی مثل سفارش، پرداخت، بازپرداخت، تخفیف، موجودی و تسویه مهم‌اند، در کد هم باید جای روشن و قابل فهم داشته باشند.

در نگاه دامنه‌محور، به جای اینکه قانون‌های مهم را در گوشه‌وکنار سیستم پخش کنیم، تلاش می‌کنیم هسته‌ی مسئله را بهتر بشناسیم و مدل کنیم. مثلاً سفارش فقط یک ردیف در جدول نیست؛ رفتاری دارد، وضعیت دارد، قاعده دارد. پرداخت فقط یک فراخوانی به سرویس بیرونی نیست؛ نتیجه، شکست، بازگشت و اثر روی سفارش دارد. تخفیف فقط یک عدد کم‌شده از قیمت نیست؛ قانون اعتبار، زمان، محدودیت و شرایط استفاده دارد.

وقتی مدل دامنه روشن‌تر باشد، تغییر دادن یک قانون کسب‌وکاری کمتر شبیه جست‌وجو در تاریکی می‌شود.

البته باید مراقب باشیم DDD را هم به یک نمایش معماری تبدیل نکنیم. طراحی دامنه‌محور یعنی از روز اول ده‌ها کلاس، اصطلاح، پوشه و مراسم پیچیده بسازیم؟ نه. اگر مسئله ساده است و قانون‌های کسب‌وکار هنوز کم و پایدارند، ساختار ساده می‌تواند کاملاً کافی باشد. DDD وقتی ارزشمند می‌شود که دامنه واقعاً پیچیده، تغییرپذیر و پرقاعده شده باشد؛ جایی که فهم مشترک از مسئله، خودش تبدیل به بخشی از کیفیت نرم‌افزار می‌شود.

برای تشخیص اینکه هنوز ساختار ساده کافی است یا باید جدی‌تر به دامنه فکر کنیم، این مقایسه کمک می‌کند:

برای من، DDD قبل از آنکه جواب آماده باشد، یک یادآوری مهم است: نرم‌افزار فقط با فریم‌ورک و پایگاه داده و API ساخته نمی‌شود؛ با فهم درست مسئله هم ساخته می‌شود. هرچه قواعد کسب‌وکار مهم‌تر و تغییرپذیرتر شوند، لازم است این فهم در خود کد هم دیده شود، نه فقط در ذهن چند نفر یا در چند سند پراکنده.

وقتی این را بپذیریم، پرسش بعدی طبیعی می‌شود: اگر منطق دامنه قلب سیستم است، چطور نگذاریم زیر فشار پایگاه داده، فریم‌ورک، API بیرونی یا ابزارهای دیگر له شود؟ این همان جایی است که معماری شش‌ضلعی وارد داستان می‌شود.

وقتی قلب سیستم نباید اسیر ابزارهای اطرافش شود​

در بخش قبل گفتیم منطق دامنه باید جای روشن‌تری در کد داشته باشد. یعنی اگر سفارش، پرداخت، بازپرداخت و تخفیف برای کسب‌وکار مهم‌اند، نباید در کنترلرها، مدل‌های پایگاه داده و چند تابع پراکنده گم شوند. اما این فقط نصف ماجراست. حتی اگر مفاهیم دامنه را خوب پیدا کنیم، باز هم ممکن است آن‌ها را زیر آوار ابزارها دفن کنیم.

فرض کنیم می‌خواهیم قانون لغو سفارش را تغییر دهیم. از نظر کسب‌وکار، قانون شاید ساده باشد: اگر سفارش هنوز وارد مرحله‌ی ارسال نشده، لغو مجاز است؛ اگر ارسال آغاز شده، باید چند شرط دیگر بررسی شود. اما وقتی وارد کد می‌شویم، می‌بینیم برای آزمودن همین قانون ساده باید پایگاه داده بالا باشد، فریم‌ورک وب اجرا شود، سرویس پرداخت شبیه‌سازی شود، تنظیمات محیطی آماده باشد و چند جزئیات فنی دیگر هم همراهش بیاید. اینجا درد اصلی روشن می‌شود: منطق دامنه را داریم، اما هنوز آزاد نیست.

در این وضعیت، منطق سفارش در مرکز دیده می‌شود، اما از هر طرف به کنترلر، پایگاه داده، صف پیام، پنل مدیریت و سرویس پرداخت کشیده شده است.

معماری شش‌ضلعی یا Hexagonal Architecture پاسخی به همین فشار است. ایده‌ی اصلی‌اش این نیست که حتماً کد را به شکل یک شش‌ضلعی واقعی بچینیم یا از روز اول پوشه‌های زیاد بسازیم. حرف اصلی ساده‌تر است: هسته‌ی سیستم، یعنی منطق اصلی کسب‌وکار، باید تا حد ممکن مستقل از ابزارهای بیرونی بماند. پایگاه داده، فریم‌ورک وب، API پرداخت، صف پیام و رابط کاربری مهم‌اند، اما نباید شکل فکر کردن دامنه را تعیین کنند.

نسبت این بحث با طراحی دامنه‌محور مهم است. DDD کمک می‌کند بفهمیم «قلب مسئله» چیست و چه واژه‌ها و قاعده‌هایی برای کسب‌وکار مهم‌اند. معماری شش‌ضلعی کمک می‌کند از همان قلب محافظت کنیم تا با تغییر پایگاه داده، فریم‌ورک وب، سرویس پرداخت یا پیام‌رسان، منطق اصلی سیستم مدام زخمی نشود. پس این دو، دو جواب جدا برای یک مسئله نیستند؛ یکی بیشتر به فهم و مدل‌کردن دامنه کمک می‌کند، دیگری به مرزبندی و محافظت از آن مدل در برابر ابزارها.

برای توضیح ساده‌ی این معماری، دو واژه‌ی مهم داریم: درگاه و سازگارکننده. درگاه یا Port یعنی هسته‌ی سیستم می‌گوید من برای انجام کارم به چه قابلیتی نیاز دارم؛ مثلاً ذخیره‌ی سفارش، گرفتن نتیجه‌ی پرداخت، ارسال پیام یا انتشار یک رخداد. سازگارکننده یا Adapter یعنی بخش بیرونی می‌آید و آن نیاز را با ابزار واقعی برآورده می‌کند؛ مثلاً با PostgreSQL، Redis، Kafka، یک API پرداخت یا هر ابزار دیگری.

در این تصویر، دامنه در مرکز است. رابط وب، پایگاه داده، صف پیام و API پرداخت دور آن قرار گرفته‌اند، نه در دل آن.

مثلاً هسته‌ی سفارش لازم نیست بداند داده‌ها دقیقاً در کدام جدول ذخیره می‌شوند. کافی است بگوید «من به چیزی نیاز دارم که سفارش را ذخیره کند». بعد یک سازگارکننده‌ی واقعی می‌تواند این نیاز را با پایگاه داده پیاده کند. اگر روزی روش ذخیره‌سازی عوض شد، نباید قانون لغو سفارش یا منطق بازپرداخت را از نو بنویسیم. تغییر باید بیشتر در لبه‌ی سیستم رخ دهد، نه در قلب آن.

این جداسازی چند فایده‌ی مهم دارد. آزمون منطق دامنه ساده‌تر می‌شود، چون برای بررسی یک قانون کسب‌وکاری لازم نیست همه‌ی ابزارهای بیرونی را بالا بیاوریم. تغییر ابزارها هم کم‌خطرتر می‌شود، چون هسته‌ی سیستم کمتر به جزئیات آن‌ها وابسته است. از همه مهم‌تر، مرز ذهنی سیستم روشن‌تر می‌شود: می‌فهمیم کدام بخش واقعاً منطق کسب‌وکار است و کدام بخش فقط راهی برای اتصال این منطق به جهان بیرون.

برای من، معماری شش‌ضلعی ادامه‌ی طبیعی DDD است. DDD کمک می‌کند بفهمیم چه چیزی قلب مسئله است؛ معماری شش‌ضلعی کمک می‌کند آن قلب را از فشار ابزارها دور نگه داریم. نه چون ابزارها بی‌اهمیت‌اند، بلکه چون ابزارها باید قابل تعویض، قابل آزمون و در خدمت دامنه باشند.

وقتی هسته‌ی دامنه جای روشن‌تری پیدا می‌کند، پرسش بعدی هم آرام‌آرام پیدا می‌شود: آیا همیشه یک مدل واحد برای خواندن و نوشتن کافی است؟ یا گاهی فشار گزارش‌گیری، نمایش داده و تغییرات پیچیده باعث می‌شود مدل خواندن و نوشتن را جدا ببینیم؟ این همان جایی است که کم‌کم به CQRS نزدیک می‌شویم.

وقتی خواندن و نوشتن نیازهای متفاوت پیدا می‌کنند​

تا اینجا تلاش کرده‌ایم قلب سیستم را بهتر بشناسیم و از ابزارهای اطرافش جدا نگه داریم. با طراحی دامنه‌محور فهمیدیم سفارش، پرداخت، بازپرداخت و تخفیف فقط چند جدول نیستند؛ هرکدام رفتار و قاعده دارند. با معماری شش‌ضلعی هم گفتیم این منطق نباید به فریم‌ورک، پایگاه داده یا API بیرونی گره بخورد. اما وقتی سیستم بزرگ‌تر می‌شود، فشار تازه‌ای پیدا می‌شود: آیا همان مدلی که برای نوشتن و اجرای قانون مناسب است، برای خواندن، گزارش‌گیری و نمایش سریع هم مناسب می‌ماند؟

فرض کنیم برای ثبت سفارش، مدل نسبتاً خوبی داریم. وقتی کاربر سفارش ثبت می‌کند، موجودی بررسی می‌شود، وضعیت پرداخت درست پیش می‌رود، تخفیف اعتبارسنجی می‌شود و قانون‌های دامنه رعایت می‌شوند. این بخش از سیستم باید دقیق و سخت‌گیر باشد؛ چون دارد وضعیت واقعی سیستم را تغییر می‌دهد.

اما از سمت دیگر، نیازهای خواندن آرام‌آرام زیاد می‌شوند. برنامه‌ی موبایل فقط یک فهرست سبک و سریع از سفارش‌های کاربر می‌خواهد. پنل مدیریت می‌خواهد سفارش‌ها را بر اساس وضعیت پرداخت، شهر، روش ارسال، کد تخفیف، مبلغ، زمان ثبت و وضعیت پشتیبانی جست‌وجو کند. داشبورد مدیریتی تعداد سفارش‌های امروز، مبلغ کل، سفارش‌های لغوشده، میانگین زمان ارسال و نرخ بازپرداخت را می‌خواهد. این‌ها بیشتر از اینکه دنبال اجرای قانون باشند، دنبال نمای مناسب، سریع و قابل جست‌وجو از داده‌ها هستند.

یک مدل واحد می‌تواند مدتی پاسخ‌گو باشد، اما وقتی نیازهای خواندن و نوشتن از دو جهت متفاوت رشد می‌کنند، همان مدل کم‌کم زیر فشار می‌رود.

اینجاست که CQRS مطرح می‌شود. CQRS کوتاه‌شده‌ی Command Query Responsibility Segregation است و می‌توان آن را «جداسازی مسئولیت فرمان و پرس‌وجو» ترجمه کرد. فرمان یعنی کاری که وضعیت سیستم را تغییر می‌دهد؛ مثل ثبت سفارش، پرداخت، لغو سفارش یا بازپرداخت. پرس‌وجو یعنی کاری که فقط داده را می‌خواند؛ مثل نمایش فهرست سفارش‌ها، گرفتن جزئیات سفارش، ساختن گزارش یا نمایش داشبورد.

در ساده‌ترین برداشت، CQRS نمی‌گوید حتماً باید دو پایگاه داده، صف پیام، Kafka یا Event Sourcing داشته باشیم. گاهی جداسازی فقط در سطح کد است: یک مسیر برای فرمان‌ها و تغییر وضعیت، یک مسیر برای پرس‌وجوها و خواندن داده. در مرحله‌های پیچیده‌تر، ممکن است مدل خواندن جدا بسازیم؛ مثلاً جدولی آماده برای گزارش یا نمایی سبک برای موبایل. در سیستم‌های بزرگ‌تر، حتی ممکن است پایگاه داده‌ی خواندن و نوشتن هم جدا شوند. اما این‌ها پله‌های مختلف‌اند، نه تعریف اجباری CQRS.

در این مدل، سمت فرمان مسئول تغییر وضعیت و رعایت قواعد دامنه است؛ سمت پرس‌وجو مسئول ساختن نماهای مناسب برای خواندن، گزارش و جست‌وجو.

نسبت CQRS با DDD و معماری شش‌ضلعی هم باید روشن باشد. DDD کمک می‌کند بفهمیم منطق دامنه چیست. معماری شش‌ضلعی کمک می‌کند این منطق را از ابزارهای بیرونی جدا نگه داریم. CQRS زمانی مطرح می‌شود که فشار خواندن و نوشتن از هم فاصله می‌گیرد. پس مسئله‌ی CQRS این نیست که «دامنه کجا باشد»، بلکه این است که «آیا مدل و مسیر خواندن باید همان مدل و مسیر نوشتن باشد؟»

این جداسازی می‌تواند چند فایده داشته باشد. مدل نوشتن می‌تواند تمیزتر و نزدیک‌تر به قواعد دامنه بماند، چون مجبور نیست همه‌ی نیازهای گزارش‌گیری و نمایش را هم در خود جا بدهد. مدل خواندن هم می‌تواند برای سرعت و شکل مناسب داده ساخته شود، بدون اینکه منطق اصلی سفارش و پرداخت را آلوده کند. برای مثال، ممکن است سمت نوشتن با مفهوم سفارش و وضعیت‌هایش کار کند، اما سمت خواندن یک نمای آماده داشته باشد که دقیقاً برای فهرست موبایل یا داشبورد مدیریتی طراحی شده است.

برای من، CQRS یک یادآوری مهم است: همه‌ی نیازهای سیستم از یک جنس نیستند. ثبت سفارش و لغو سفارش باید دقیق، قانون‌مند و محافظه‌کار باشد. فهرست سفارش‌ها و گزارش مدیریتی باید سریع، قابل جست‌وجو و مناسب نمایش باشد. اگر این دو نیاز هنوز ساده‌اند، یک مدل واحد کافی است. اما وقتی از هم فاصله گرفتند، جدا دیدن آن‌ها می‌تواند سیستم را قابل فهم‌تر و قابل تغییرتر کند.

این جداسازی آرام‌آرام ما را به یک سؤال بعدی می‌رساند: اگر تغییرهای مهم سیستم را فقط به‌صورت وضعیت نهایی ذخیره نکنیم و خود رخدادهای مهم را هم نگه داریم چه می‌شود؟ اینجا وارد بحث Event Sourcing می‌شویم.

وقتی سیستم باید خبر بدهد، نه اینکه همه را مستقیم صدا بزند​

تا اینجا چند بار با یک الگوی تکرارشونده روبه‌رو شدیم: هرچه محصول رشد می‌کند، یک تصمیم ساده‌ی دیروز کم‌کم زیر فشار نیازهای تازه قرار می‌گیرد. در CQRS گفتیم خواندن و نوشتن ممکن است نیازهای متفاوتی پیدا کنند. حالا می‌خواهیم از زاویه‌ی دیگری به رشد سیستم نگاه کنیم: وقتی یک اتفاق در سیستم می‌افتد، چند بخش دیگر باید از آن باخبر شوند؟

فرض کنیم کاربر سفارشی ثبت می‌کند و پرداخت هم موفق می‌شود. در نگاه ساده، شاید بگوییم سفارش ثبت شد و تمام. اما در محصول واقعی، این اتفاق فقط برای سرویس سفارش مهم نیست. موجودی باید کم شود، برای کاربر اعلان فرستاده شود، داشبورد فروش باید به‌روز شود، گزارش مالی بعداً باید آن را حساب کند، و شاید سیستم امتیازدهی هم بخواهد به رفتار کاربر واکنش نشان دهد.

اگر سرویس سفارش بخواهد همه‌ی این کارها را خودش و به‌صورت مستقیم انجام دهد، خیلی زود گرفتار زنجیره‌ای از وابستگی‌ها می‌شود. باید سرویس اعلان را بشناسد، سرویس موجودی را صدا بزند، گزارش مالی را خبر کند، داشبورد را به‌روز کند و با سیستم امتیازدهی هم هماهنگ شود. حالا اگر یکی از این بخش‌ها کند یا خراب شود، مسیر اصلی ثبت سفارش هم ممکن است آسیب ببیند.

وقتی یک سرویس مجبور است همه‌ی واکنش‌های بعد از یک اتفاق را خودش مدیریت کند، وابستگی‌ها زیاد و شکننده می‌شوند.

معماری رویدادمحور یا Event-Driven Architecture از همین‌جا معنا پیدا می‌کند. ایده‌اش این است که به‌جای اینکه سرویس سفارش همه را مستقیم صدا بزند، فقط یک خبر رسمی منتشر کند: «سفارش ثبت شد». بعد هر بخشی که به این اتفاق علاقه دارد، واکنش خودش را انجام می‌دهد. سرویس اعلان پیام می‌فرستد، سرویس موجودی مقدار کالا را کم می‌کند، داشبورد داده‌ی خودش را به‌روز می‌کند و گزارش مالی هم مسیر خودش را می‌رود.

رویداد با دستور مستقیم فرق دارد. وقتی می‌گوییم «سفارش ثبت شد»، داریم درباره‌ی چیزی خبر می‌دهیم که قبلاً رخ داده است. اما وقتی می‌گوییم «به کاربر پیامک بفرست»، داریم به یک بخش دیگر دستور می‌دهیم کاری انجام دهد. این تفاوت کوچک، در طراحی سیستم مهم است. رخداد، سرویس منتشرکننده را از دانستن جزئیات واکنش‌های بعدی آزادتر می‌کند.

سرویس سفارش لازم نیست همه‌ی مصرف‌کننده‌ها را بشناسد؛ فقط خبر رسمی اتفاق را منتشر می‌کند.

برای رساندن این رخدادها معمولاً یک پیام‌رسان یا واسط ارتباطی در میان قرار می‌گیرد؛ چیزی که پیام را از تولیدکننده می‌گیرد و به مصرف‌کننده‌ها می‌رساند. در این بخش لازم نیست وارد جزئیات ابزارهایی مثل Kafka یا RabbitMQ شویم؛ فعلاً همین قدر کافی است که بدانیم پیام‌رسان کمک می‌کند تولیدکننده‌ی رخداد و مصرف‌کننده‌های آن کمتر به هم قفل شوند. جزئیات صف پیام، الگوهای مصرف، تکرار پیام و تفاوت ابزارها را جداگانه در بخش Message Queue باز می‌کنیم.

نکته‌ی مهم این است که معماری رویدادمحور فقط مزیت نیست؛ پیچیدگی تازه هم می‌آورد. در مدل مستقیم، مسیر اجرا معمولاً واضح‌تر است: این سرویس آن سرویس را صدا زد و پاسخ گرفت. اما در مدل رویدادمحور، یک رخداد منتشر می‌شود و چند مصرف‌کننده بعداً واکنش نشان می‌دهند. ممکن است پیام دیر برسد، دوباره برسد، مصرف‌کننده‌ای موقتاً از کار بیفتد، یا فهمیدن مسیر کامل یک اتفاق سخت‌تر شود. پس آزادی بیشتر، با مسئولیت عملیاتی بیشتر همراه است.

اینجا بد نیست خیلی کوتاه مرز CDC را هم روشن کنیم. گرفتن تغییرات داده یا Change Data Capture، که معمولاً CDC گفته می‌شود، یعنی تغییرهای پایگاه داده را دنبال کنیم و آن‌ها را به جریان پیام یا رخداد تبدیل کنیم. مثلاً وقتی ردیفی در جدول سفارش‌ها اضافه می‌شود یا وضعیت سفارشی تغییر می‌کند، CDC می‌تواند این تغییر را بخواند و برای بخش‌های دیگر منتشر کند.

برای اینکه مرز این مفهوم‌ها با بخش‌های قبلی و بعدی روشن بماند، می‌شود این‌طور نگاه کرد:

برای من، معماری رویدادمحور یعنی پذیرفتن اینکه بعضی اتفاق‌ها فقط متعلق به یک بخش نیستند. سفارش ثبت می‌شود، اما اعلان، موجودی، داشبورد و گزارش هم از آن تأثیر می‌گیرند. به‌جای اینکه سرویس سفارش همه را مستقیم بشناسد، می‌تواند خبر رسمی اتفاق را منتشر کند و بقیه‌ی بخش‌ها مستقل‌تر واکنش نشان دهند.

تا اینجا رخدادها را مثل خبرهایی دیدیم که بین بخش‌های سیستم جابه‌جا می‌شوند. اما اگر این رخدادها فقط پیام گذرا نباشند و خودشان منبع اصلی حقیقت سیستم شوند چه؟ این پرسش ما را به Event Sourcing می‌رساند.

وقتی پیام‌ها باید امن و قابل‌اعتماد جابه‌جا شوند​

در بخش قبل گفتیم معماری رویدادمحور کمک می‌کند سرویس‌ها به‌جای صدا زدن مستقیم یکدیگر، خبر اتفاق‌های مهم را منتشر کنند. سرویس سفارش لازم نیست خودش اعلان بفرستد، موجودی کم کند، داشبورد را به‌روز کند و گزارش مالی بسازد. می‌تواند بگوید «سفارش ثبت شد» و بخش‌های علاقه‌مند، هرکدام واکنش خودشان را انجام دهند.

اما این حرف یک پرسش عملی مهم را باز می‌گذارد: این پیام‌ها قرار است از کجا عبور کنند؟ اگر سرویس اعلان لحظه‌ای از کار افتاده باشد چه؟ اگر سرویس گزارش مالی کندتر از بقیه پردازش کند چه؟ اگر پیام به مصرف‌کننده رسید اما پردازش آن شکست خورد چه؟ اینجاست که صف پیام یا Message Queue وارد داستان می‌شود.

صف پیام را می‌توان مثل یک فضای میانی میان تولیدکننده و مصرف‌کننده دید. تولیدکننده پیام را در صف می‌گذارد و لازم نیست منتظر بماند همه‌ی مصرف‌کننده‌ها همان لحظه کارشان را انجام دهند. مصرف‌کننده‌ها هم با سرعت و توان خودشان پیام‌ها را می‌خوانند و پردازش می‌کنند. این فاصله‌ی کوچک، در سیستم‌های بزرگ ارزش زیادی دارد؛ چون دو طرف را از وضعیت لحظه‌ای هم آزادتر می‌کند.

تولیدکننده پیام را در صف می‌گذارد و مصرف‌کننده‌ها مستقل از هم آن را پردازش می‌کنند.

در ساده‌ترین شکل، چند نقش اصلی داریم. تولیدکننده یا Producer بخشی است که پیام را می‌فرستد؛ مثلاً سرویس سفارش. مصرف‌کننده یا Consumer بخشی است که پیام را می‌خواند و کاری انجام می‌دهد؛ مثلاً سرویس اعلان یا گزارش مالی. خود صف یا موضوع، جایی است که پیام‌ها در آن قرار می‌گیرند. بعضی ابزارها بیشتر با واژه‌ی صف شناخته می‌شوند، بعضی با مفهوم جریان یا موضوع، اما ایده‌ی پایه یکی است: پیام‌ها باید جایی قرار بگیرند تا بین بخش‌های سیستم جابه‌جا شوند.

اینجا تفاوت Message Queue با معماری رویدادمحور هم مهم است. معماری رویدادمحور می‌گوید بخش‌های سیستم می‌توانند با خبر دادن درباره‌ی اتفاق‌ها با هم هماهنگ شوند. صف پیام بیشتر درباره‌ی زیرساخت رساندن آن خبرهاست. یعنی EDA بیشتر سبک طراحی ارتباط است، اما Message Queue ابزار و سازوکاری است برای اینکه این ارتباط عملی‌تر، قابل تحمل‌تر و قابل بازیابی‌تر شود.

یکی از نکته‌های مهم در صف پیام، تأیید پردازش است. مصرف‌کننده معمولاً بعد از اینکه پیام را گرفت و کارش را انجام داد، به صف اعلام می‌کند که پیام با موفقیت پردازش شده است. اگر پردازش شکست بخورد، سیستم می‌تواند پیام را دوباره برای تلاش بعدی نگه دارد یا بعد از چند بار شکست، آن را به جای جداگانه‌ای بفرستد تا بعداً بررسی شود. به این جای جداگانه معمولاً صف پیام‌های مشکل‌دار یا Dead Letter Queue گفته می‌شود.

همه‌ی خطاها نباید مسیر اصلی را متوقف کنند؛ بعضی پیام‌ها می‌توانند دوباره پردازش شوند یا برای بررسی جدا شوند.

اما صف پیام هم جادو نمی‌کند. وقتی پیام‌ها غیرهم‌زمان جابه‌جا می‌شوند، باید با چند واقعیت کنار بیاییم. ممکن است یک پیام بیش از یک بار به مصرف‌کننده برسد، پس مصرف‌کننده باید تا حد ممکن در برابر پردازش تکراری مقاوم باشد. ممکن است ترتیب پیام‌ها مهم باشد، پس باید بدانیم ابزار و طراحی ما چه تضمینی درباره‌ی ترتیب می‌دهد. ممکن است مصرف‌کننده عقب بماند و صف بزرگ شود. ممکن است پیام‌ها در یک بخش پردازش شوند و در بخش دیگر هنوز نه، و این یعنی سیستم برای مدتی در وضعیت کاملاً هم‌زمان و یکدست نیست.

در این فضا نام ابزارهایی مثل RabbitMQ و Kafka زیاد شنیده می‌شود. برای فهم اولیه، می‌شود خیلی ساده گفت RabbitMQ بیشتر با الگوی صف، تحویل پیام و پردازش کارها شناخته می‌شود. Kafka بیشتر شبیه یک جریان پایدار از پیام‌ها و رخدادهاست که پیام‌ها را برای مدتی نگه می‌دارد و مصرف‌کننده‌های مختلف می‌توانند از آن بخوانند. این توضیح کامل نیست، اما برای جایگاه ذهنی کافی است: هر دو برای جابه‌جایی پیام استفاده می‌شوند، اما نگاه و نقطه‌ی قوتشان یکسان نیست.

برای من، صف پیام یعنی پذیرفتن اینکه همه‌ی بخش‌های سیستم لازم نیست هم‌زمان و مستقیم به هم قفل باشند. بعضی کارها می‌توانند کمی دیرتر، مستقل‌تر و با امکان تلاش دوباره انجام شوند. این استقلال ارزشمند است، اما فقط وقتی که هزینه‌های عملیاتی آن را هم بپذیریم.

تا اینجا فقط درباره‌ی مسیر جابه‌جایی پیام‌ها حرف زدیم: پیام از کجا عبور کند، اگر مصرف‌کننده کند بود چه شود، اگر پردازش شکست خورد چطور دوباره تلاش کنیم، و پیام‌های مشکل‌دار را کجا نگه داریم. بخش بعدی یک پرسش جداست: گاهی خود رخدادها فقط پیام عبوری نیستند و برای فهم تاریخچه‌ی سیستم اهمیت پیدا می‌کنند. آنجا وارد Event Sourcing می‌شویم.

وقتی فقط وضعیت فعلی کافی نیست​

در بخش‌های قبل، رخدادها را از دو زاویه دیدیم. در معماری رویدادمحور، رخداد راهی بود برای خبر دادن به بخش‌های دیگر سیستم. در صف پیام، درباره‌ی این حرف زدیم که پیام‌ها و رخدادها چطور میان تولیدکننده و مصرف‌کننده جابه‌جا شوند. اما Event Sourcing پرسش دیگری دارد: اگر خود رخدادها فقط پیام عبوری نباشند و تاریخچه‌ی رسمی سیستم را بسازند چه؟

فرض کنیم کاربری به پشتیبانی پیام می‌دهد و می‌گوید: «من سفارشم را لغو کردم، ولی چرا فقط بخشی از پولم برگشته؟» پشتیبانی وارد پنل می‌شود و فقط یک چیز می‌بیند: وضعیت سفارش «لغوشده» است. این اطلاعات بد نیست، اما کافی هم نیست. برای فهمیدن ماجرا باید بدانیم سفارش چه زمانی ثبت شد، پرداخت چه زمانی انجام شد، لغو قبل از ارسال بود یا بعد از آن، لغو را خود کاربر انجام داد یا پشتیبانی، قانون بازپرداخت در آن لحظه چه بوده، و آیا بازپرداخت کامل شده یا فقط آغاز شده است.

اینجا مشکل روشن می‌شود: وضعیت فعلی فقط آخر داستان را نشان می‌دهد، نه مسیر رسیدن به آن را.

اگر فقط بدانیم سفارش «لغوشده» است، هنوز نمی‌دانیم چه اتفاق‌هایی باعث رسیدن سفارش به این وضعیت شده‌اند.

در مدل معمول، بیشتر با وضعیت فعلی کار می‌کنیم. مثلاً در جدول سفارش، یک فیلد داریم که می‌گوید سفارش الان پرداخت‌شده، ارسال‌شده یا لغوشده است. اما در Event Sourcing، منبع اصلی حقیقت فقط وضعیت نهایی نیست؛ رخدادهایی است که در طول زمان اتفاق افتاده‌اند. یعنی به جای اینکه فقط بگوییم سفارش الان چه وضعیتی دارد، تاریخچه‌ی اتفاق‌ها را نگه می‌داریم.

برای یک سفارش، این رخدادها می‌توانند چنین چیزهایی باشند: سفارش ثبت شد، پرداخت انجام شد، ارسال آغاز شد، سفارش لغو شد، بازپرداخت صادر شد. بعد وضعیت فعلی سفارش از روی همین رخدادها ساخته می‌شود. در این نگاه، وضعیت فعلی نتیجه‌ی تاریخچه است؛ نه جایگزین تاریخچه.

رخدادها فقط خبرهای پراکنده نیستند؛ تاریخچه‌ای هستند که وضعیت فعلی از روی آن‌ها ساخته می‌شود.

مرز این مفهوم با فصل‌های قبلی مهم است. در معماری رویدادمحور، شاید رخداد را برای خبر دادن به سرویس‌های دیگر منتشر کنیم. در صف پیام، درباره‌ی رساندن و پردازش همین پیام‌ها حرف زدیم. اما در Event Sourcing، رخدادها نقش عمیق‌تری دارند: آن‌ها حافظه‌ی رسمی سیستم‌اند. حتی اگر هیچ سرویس دیگری رخدادها را مصرف نکند، خود سیستم می‌تواند برای بازسازی وضعیت، حسابرسی یا تحلیل خطا به آن‌ها تکیه کند.

Event Sourcing را نباید با لاگ معمولی هم یکی گرفت. لاگ عملیاتی معمولاً برای مشاهده، عیب‌یابی و فهم رفتار سیستم نوشته می‌شود. اما رخداد در Event Sourcing بخشی از مدل اصلی سیستم است. اگر رخدادهای سفارش را از دست بدهیم، فقط چند خط گزارش را از دست نداده‌ایم؛ بخشی از حقیقت سیستم را از دست داده‌ایم.

همچنین Event Sourcing الزاماً همان CQRS نیست. ممکن است سیستمی CQRS داشته باشد، اما رخدادها را منبع حقیقت نداند. ممکن است Event Sourcing داشته باشیم و بعد برای خواندن سریع‌تر، مدل‌های خواندن جدا بسازیم؛ در این حالت این دو کنار هم می‌آیند. اما یکی تعریف دیگری نیست. CQRS درباره‌ی جداسازی خواندن و نوشتن است؛ Event Sourcing درباره‌ی این است که وضعیت از روی رخدادهای ذخیره‌شده ساخته شود.

این سبک چند مزیت جدی دارد. برای حسابرسی و پشتیبانی، تاریخچه‌ی دقیق‌تری از اتفاق‌ها داریم. اگر لازم باشد بفهمیم چرا یک سفارش به وضعیت فعلی رسیده، می‌توانیم مسیر رخدادها را دنبال کنیم. اگر باگی در محاسبه‌ی وضعیت پیدا شود، گاهی می‌توان با منطق اصلاح‌شده، وضعیت را از روی رخدادهای گذشته دوباره ساخت. همچنین می‌توان از همان تاریخچه برای ساختن نماهای خواندن، گزارش‌ها یا تحلیل‌های تازه استفاده کرد.

اما این مزایا ارزان به دست نمی‌آیند. ترتیب رخدادها مهم می‌شود. نسخه‌بندی رخدادها دردسر دارد؛ چون رخدادهای قدیمی ممکن است با شکل جدید کد یکی نباشند. بازسازی وضعیت باید دقیق و قابل اعتماد باشد. حذف یا اصلاح داده‌ها ساده نیست، چون تاریخچه بخشی از حقیقت سیستم است. خواندن داده هم گاهی مستقیم و ساده مثل خواندن یک ردیف از جدول نیست و به مدل‌های خواندن جدا نیاز پیدا می‌کند.

برای من، Event Sourcing یعنی به رسمیت شناختن این نکته که گاهی «چه اتفاقی افتاد» مهم‌تر از «الان در چه وضعیتی هستیم» است. وضعیت فعلی لازم است، اما همیشه کافی نیست. وقتی تاریخچه بخشی از حقیقت سیستم می‌شود، رخدادها دیگر فقط پیام نیستند؛ حافظه‌ی رسمی سیستم‌اند.

تا اینجا بیشتر درباره‌ی شکل ارتباط و مدل‌سازی رفتار سیستم حرف زدیم. از اینجا به بعد کم‌کم باید به سراغ زیرساخت و اجرای قابل تکرار برویم: اینکه محیط‌ها، تنظیمات، سرویس‌ها و منابع زیرساختی را چطور قابل بازسازی و قابل کنترل نگه داریم. این همان جایی است که Infrastructure as Code وارد داستان می‌شود.

وقتی «روی سیستم من کار می‌کند» دیگر کافی نیست​

تقریباً هر تیم نرم‌افزاری، دیر یا زود، با این جمله روبه‌رو می‌شود: «روی سیستم من کار می‌کند.» برنامه روی لپ‌تاپ توسعه‌دهنده اجرا می‌شود، آزمون‌ها سبزند، همه‌چیز ظاهراً درست است؛ اما وقتی همان کد به محیط تست یا تولید می‌رود، خطا می‌دهد. چرا؟ شاید نسخه‌ی Python فرق دارد، شاید یک کتابخانه‌ی سیستمی نصب نیست، شاید متغیر محیطی جا افتاده، شاید مسیر فایل‌ها فرق می‌کند، یا شاید نسخه‌ی PostgreSQL و Redis با محیط توسعه یکی نیست.

اینجا یک نکته‌ی مهم روشن می‌شود: کد برنامه فقط خودش نیست. برنامه همراه با نسخه‌ی زبان، وابستگی‌ها، کتابخانه‌های سیستمی، تنظیمات، مسیرها، دستور اجرا و حتی فرض‌های پنهانی درباره‌ی محیط اجرا معنی پیدا می‌کند. اگر این محیط در هرجا کمی فرق کند، همان کد می‌تواند رفتار متفاوتی داشته باشد.

مسئله همیشه خود کد نیست؛ گاهی محیط اجرا عوض شده و همان تغییر کوچک کافی است تا برنامه در محیط دیگر خراب شود.

این درد تازه نیست. پیش از فراگیر شدن کانتینرها، یکی از راه‌حل‌های رایج این بود که محیط کامل‌تری را با ماشین مجازی یا VM بسازیم. ماشین مجازی کمک می‌کرد یک سیستم‌عامل کامل‌تر و جداگانه‌تر داشته باشیم، اما هزینه‌اش هم کم نبود: سنگین‌تر بود، بالا آمدنش زمان بیشتری می‌گرفت، و برای هر برنامه انگار یک رایانه‌ی کوچک جداگانه روشن می‌کردیم.

کانتینرها از همین‌جا جذاب شدند. ایده‌ی جداسازی سبک‌تر فرایندها در لینوکس قدیمی‌تر از Docker بود، اما Docker حدود سال ۲۰۱۳ این تجربه را برای توسعه‌دهنده‌ها بسیار ساده‌تر و فراگیرتر کرد. جذابیت Docker این بود که یک زبان روزمره به تیم‌ها داد: یک فایل بنویس، وابستگی‌ها و دستور اجرا را مشخص کن، image بساز، و همان image را در محیط‌های مختلف اجرا کن. به زبان ساده، Docker مشکل «این برنامه دقیقاً با چه محیطی اجرا می‌شود؟» را قابل کنترل‌تر کرد.

فرض کنیم سرویس سفارش با Python نوشته شده است. بدون کانتینر، ممکن است روی هر سرور دستی Python نصب کنیم، پکیج‌ها را نصب کنیم، تنظیمات را بچینیم و امیدوار باشیم همه‌چیز شبیه محیط توسعه است. با Docker معمولاً یک Dockerfile می‌نویسیم و در آن مشخص می‌کنیم از چه نسخه‌ای از Python استفاده شود، چه وابستگی‌هایی نصب شود، کد کجا کپی شود و دستور اجرای برنامه چیست. بعد از روی آن یک image ساخته می‌شود.

از Dockerfile یک image ساخته می‌شود؛ image مثل بسته‌ی آماده و ثابت برنامه است، container اجرای زنده‌ی همان image است، و registry جایی است که imageها را در آن نگه‌داری و جابه‌جا می‌کنیم.

چند واژه‌ی پایه‌ای اینجا مهم‌اند:

تا اینجا Docker و کانتینر کمک می‌کنند برنامه را تمیزتر و قابل حمل‌تر اجرا کنیم. اما این پایان داستان نیست. وقتی فقط یک سرویس کوچک داریم، شاید Docker یا Docker Compose برای توسعه و حتی بعضی استقرارهای ساده کافی باشد. Docker Compose ابزاری است که اجازه می‌دهد چند کانتینر مرتبط را با یک فایل کنار هم تعریف و اجرا کنیم؛ مثلاً برنامه، پایگاه داده و Redis را برای محیط توسعه با یک دستور بالا بیاوریم. Compose کمک می‌کند اجرای چندتکه‌ی یک برنامه ساده‌تر شود، اما معمولاً برای مدیریت جدی سرویس‌ها در مقیاس تولید، جای Kubernetes را نمی‌گیرد.

وقتی محصول بزرگ‌تر می‌شود و چند سرویس داریم، مسئله‌ها عوض می‌شوند: سرویس سفارش، پرداخت، کاربر، اعلان، گزارش، workerها، پایگاه داده، صف پیام و چند نسخه‌ی هم‌زمان از سرویس‌ها.

حالا پرسش‌های تازه‌ای داریم. اگر کانتینر سرویس سفارش خراب شد، چه کسی دوباره آن را بالا بیاورد؟ اگر ترافیک زیاد شد، چه کسی تعداد نمونه‌ها را بیشتر کند؟ اگر نسخه‌ی جدید منتشر کردیم، چطور آرام‌آرام جایگزین نسخه‌ی قدیمی شود؟ سرویس پرداخت چطور آدرس پایدار سرویس سفارش را پیدا کند؟ تنظیمات غیرحساس و رمزها کجا نگه‌داری شوند؟ از کجا بفهمیم یک نمونه سالم است یا باید از مسیر ترافیک خارج شود؟

اینجا Kubernetes وارد داستان می‌شود. Kubernetes را گوگل در سال ۲۰۱۴ معرفی کرد و طراحی آن از تجربه‌ی داخلی گوگل در اجرای workloadهای بزرگ، به‌ویژه سامانه‌هایی مثل Borg، الهام گرفته بود. نسخه‌ی ۱.۰ آن در سال ۲۰۱۵ منتشر شد و بعدتر به یکی از پایه‌های مهم دنیای cloud-native تبدیل شد. اگر Docker به توسعه‌دهنده‌ها گفت «برنامه را قابل بسته‌بندی‌تر کن»، Kubernetes گفت «حالا تعداد زیادی از این بسته‌ها را در یک محیط واقعی مدیریت کن».

Kubernetes یک هماهنگ‌کننده یا orchestrator است. یعنی ما وضعیت مطلوب را به آن می‌گوییم، و Kubernetes تلاش می‌کند آن وضعیت را حفظ کند. مثلاً می‌گوییم از سرویس سفارش همیشه سه نمونه در حال اجرا باشد. اگر یکی از آن‌ها خراب شود، Kubernetes تلاش می‌کند نمونه‌ی تازه‌ای بالا بیاورد. اگر نسخه‌ی جدید منتشر کنیم، می‌تواند نسخه‌ی قدیمی را کم‌کم با نسخه‌ی تازه جایگزین کند. اگر بخواهیم سرویس‌ها همدیگر را پیدا کنند، برایشان آدرس پایدار فراهم می‌کند.

کانتینرها برنامه را قابل بسته‌بندی‌تر می‌کنند؛ Kubernetes اجرای تعداد زیادی کانتینر را در محیط واقعی هماهنگ می‌کند.

برای فهم اولیه‌ی Kubernetes، این چند مفهوم کافی است:

یک مثال ساده را در نظر بگیریم. ما سرویس سفارش را containerize می‌کنیم و image آن را در registry می‌گذاریم. بعد در Kubernetes یک Deployment تعریف می‌کنیم که بگوید سه نمونه از این سرویس اجرا شود. یک Service هم تعریف می‌کنیم تا بقیه‌ی سرویس‌ها لازم نباشد آدرس تک‌تک Podها را بدانند. تنظیماتی مثل نام صف یا آدرس سرویس‌های داخلی می‌تواند در ConfigMap بیاید، و چیزهایی مثل رمز اتصال به پایگاه داده در Secret نگه‌داری شود. اگر یکی از Podها خراب شود، Kubernetes تلاش می‌کند نمونه‌ی جایگزین بالا بیاورد. اگر نسخه‌ی تازه‌ای از image منتشر کنیم، Deployment می‌تواند rollout انجام دهد.

این‌ها کمک می‌کنند اجرای سرویس‌ها از حالت «چند دستور دستی روی چند ماشین» به وضعیتی نزدیک‌تر شود که قابل تعریف، قابل پیگیری و قابل تکرار است. اما نباید دچار خیال‌پردازی شویم: Kubernetes پیچیدگی عملیاتی جدی دارد. خود خوشه باید نصب، نگه‌داری، پایش، امن‌سازی و به‌روزرسانی شود. اگر تیم هنوز یک برنامه‌ی ساده دارد، شاید Docker Compose، یک ماشین مجازی، یک سکوی ساده‌ی میزبانی یا حتی یک PaaS انتخاب بهتری باشد.

برای من، کانتینرها پاسخ به یک درد خیلی انسانی‌اند: «چرا این برنامه اینجا کار می‌کند و آنجا نه؟» و Kubernetes پاسخ به درد مرحله‌ی بعدی است: «حالا که همه‌چیز را کانتینری کردیم، چه کسی این همه اجرا را در محیط واقعی زنده، سالم، قابل کشف و قابل به‌روزرسانی نگه دارد؟» این دو یکی نیستند، اما به هم وصل‌اند. Docker بیشتر درباره‌ی بسته‌بندی و اجرای تکرارپذیر است؛ Docker Compose اجرای چند کانتینر مرتبط را ساده‌تر می‌کند؛ Kubernetes بیشتر درباره‌ی هماهنگ‌کردن و نگه‌داری تعداد زیادی اجرای کانتینری در محیط واقعی است.

تا اینجا درباره‌ی سرویس‌هایی حرف زدیم که واقعاً باید اجرا شوند، نسخه داشته باشند، در دسترس بمانند و در محیط‌های مختلف قابل تکرار باشند. اما همه‌ی کارهای سیستم از جنس سرویس دائمی نیستند. بعضی کارها فقط گاهی و در واکنش به یک رخداد، پیام، زمان‌بندی یا وبهوک اجرا می‌شوند. آیا برای آن‌ها هم باید Deployment یا worker همیشه‌روشن داشته باشیم؟ این همان پرسشی است که ما را به Serverless می‌رساند.

وقتی بعضی کارها ارزش سرویس دائمی ندارند​

تا اینجا درباره‌ی سرویس‌هایی حرف زده‌ایم که باید قابل اجرا، قابل بسته‌بندی و قابل مدیریت باشند. اما همه‌ی کارهای سیستم از جنس سرویس دائمی نیستند. بعضی کارها کوتاه، پراکنده و واکنشی‌اند: رسیدگی به یک وبهوک پرداخت، ساخت تصویر بندانگشتی بعد از آپلود فایل، تولید یک گزارش سبک زمان‌بندی‌شده، پاک‌سازی داده‌های موقت، یا ارسال اعلان بعد از رسیدن یک پیام.

سؤال اصلی این فصل این است: آیا برای هر کار کوتاه و مقطعی باید یک سرویس یا worker همیشه‌روشن نگه داریم؟ گاهی جواب بله است، اما همیشه نه. اگر کاری فقط هنگام رسیدن یک رخداد یا زمان‌بندی خاص اجرا می‌شود، شاید بتوان آن را به شکل تابع یا واحد اجرایی کوتاه‌عمر اجرا کرد؛ چیزی که فقط هنگام نیاز روشن می‌شود و بعد از پایان کار، دیگر لازم نیست مثل یک سرویس دائمی زنده بماند.

وقتی کارها کوتاه و پراکنده‌اند، نگه داشتن یک سرویس همیشه‌روشن ممکن است بیش از نیاز واقعی هزینه و پیچیدگی بسازد.

معماری بی‌سرور یا Serverless Architecture از همین پرسش شروع می‌شود. نامش کمی گمراه‌کننده است: بی‌سرور یعنی سروری وجود ندارد؟ نه. سرور هست، اما ما به‌صورت مستقیم آن را مدیریت نمی‌کنیم. در این مدل، معمولاً منطق کوچک و مشخصی را به شکل تابع تعریف می‌کنیم و سکوی اجرا آن را هنگام نیاز اجرا می‌کند: با یک درخواست HTTP، با یک پیام در صف، با یک زمان‌بندی، با آپلود فایل، یا با رسیدن یک وبهوک.

برای ملموس‌تر شدن، فرض کنید سرویس پرداخت بعد از موفق شدن پرداخت، یک وبهوک به سیستم ما می‌فرستد. در مدل معمول، ممکن است یک سرویس همیشه‌روشن داشته باشیم که منتظر این درخواست‌ها بماند. در مدل Serverless، می‌توانیم یک تابع کوچک تعریف کنیم که فقط وقتی این وبهوک رسید اجرا شود: امضای درخواست را بررسی کند، تکراری نبودن پیام را بسنجد، وضعیت پرداخت را ذخیره کند، و اگر لازم بود یک پیام برای ادامه‌ی پردازش منتشر کند. بعد از تمام شدن کار، تابع هم تمام می‌شود.

در عمل، این مدل را با ابزارها و سکوهای مختلفی می‌بینیم. در دنیای ابری، نام‌هایی مثل AWS Lambda، Google Cloud Functions، Azure Functions، Cloudflare Workers، Vercel Functions و Netlify Functions زیاد شنیده می‌شوند. در فضای نزدیک به Kubernetes هم ابزارهایی مثل Knative و OpenFaaS مطرح می‌شوند. هدف این نوشته مقایسه‌ی این ابزارها نیست؛ فقط می‌خواهیم جای ذهنی‌شان روشن شود: این‌ها کمک می‌کنند کدی کوچک را در واکنش به یک محرک اجرا کنیم، بدون اینکه خودمان مستقیماً یک سرویس دائمی برای آن نگه داریم.

در این مدل، تابع فقط هنگام نیاز اجرا می‌شود و بعد از پایان کار، لازم نیست به‌عنوان یک سرویس دائمی روشن بماند.

اینجا ممکن است یک پرسش طبیعی پیش بیاید: «خب فرق این با Celery چیست؟ Celery هم کار پس‌زمینه اجرا می‌کند.» شباهتشان این است که هر دو می‌توانند برای کارهای غیرهم‌زمان و خارج از مسیر اصلی درخواست استفاده شوند؛ مثلاً ارسال ایمیل، پردازش فایل یا اجرای یک کار زمان‌بر. اما تفاوت اصلی در مدل اجرا و مالکیت زیرساخت است. در Celery معمولاً خودمان workerها را اجرا و مدیریت می‌کنیم، یک broker مثل Redis یا RabbitMQ داریم، و ظرفیت، استقرار، پایش و مقیاس‌دهی workerها با خودمان است. در Serverless، اجرای تابع و بخشی از مقیاس‌دهی را به سکوی اجرا می‌سپاریم.

بحث هزینه اینجا مهم است، اما باید با احتیاط درباره‌اش حرف زد. گاهی Serverless برای کارهای کم‌تعداد، کوتاه و پراکنده جذاب است، چون به جای روشن نگه داشتن یک سرویس دائمی، بیشتر هنگام اجرا هزینه می‌دهیم. اگر کاری روزی چند بار اجرا شود یا فقط هنگام رخدادهای خاص لازم باشد، این مدل می‌تواند به‌صرفه‌تر باشد.

اما این همیشه به معنی ارزان‌تر بودن نیست. اگر تابع‌ها بسیار پرتعداد اجرا شوند، زمان اجرای طولانی داشته باشند، داده‌ی زیادی جابه‌جا کنند، یا زنجیره‌ای از تابع‌های کوچک پشت سر هم راه بیفتد، هزینه می‌تواند غافلگیرکننده شود. حتی اگر هزینه‌ی مالی خوب به نظر برسد، هزینه‌ی خطایابی، مشاهده‌پذیری، وابستگی به ارائه‌دهنده و پیچیدگی عملیاتی هم باید حساب شود.

Serverless چند چالش فنی هم دارد. یکی از شناخته‌شده‌ترین آن‌ها شروع سرد یا Cold Start است؛ یعنی تابعی که مدتی اجرا نشده، ممکن است در نخستین اجرا کمی دیرتر آماده شود. محدودیت زمان اجرا هم مهم است؛ بسیاری از بسترهای Serverless برای پردازش‌های خیلی طولانی مناسب نیستند. از طرف دیگر، اگر تابع‌ها زیاد و پراکنده شوند، دنبال کردن مسیر یک خطا از میان چند تابع کوچک سخت‌تر می‌شود. همچنین ممکن است به قراردادها و ابزارهای یک ارائه‌دهنده‌ی خاص وابسته شویم.

برای من، Serverless یعنی لازم نیست برای هر کار کوچک، یک چراغ همیشه روشن نگه داریم. بعضی کارها فقط وقتی باید اجرا شوند که چیزی اتفاق افتاده، پیامی رسیده، زمانی فرا رسیده یا فایلی بارگذاری شده است. اما همین آزادی اگر بدون فهم هزینه، محدودیت و مشاهده‌پذیری بیاید، می‌تواند سیستم را پراکنده و سخت‌فهم کند.

وقتی سرویس‌های دائمی، کارهای کوتاه‌عمر و منابع اجرایی زیاد می‌شوند، یک پرسش تازه پیدا می‌شود: این همه تعریف، تنظیم، دسترسی، صف، تابع، سرویس و محیط را چطور قابل تکرار و قابل بازبینی نگه داریم؟ این همان جایی است که Infrastructure as Code وارد داستان می‌شود.

وقتی زیرساخت هم باید قابل بازبینی باشد​

تا اینجا درباره‌ی سرویس‌ها، کانتینرها، Kubernetes و Serverless حرف زدیم. کم‌کم سیستم ما فقط چند فایل کد نیست؛ پایگاه داده دارد، صف پیام دارد، شبکه دارد، کلاستر دارد، دسترسی دارد، تنظیمات محیطی دارد و برای هر محیط، از آزمایشی تا تولید، باید شکل نسبتاً قابل اعتمادی داشته باشد.

اما اینجا یک درد آشنا دوباره برمی‌گردد. یک نفر می‌خواهد محیط آزمایشی را شبیه تولید بسازد و می‌پرسد: نسخه‌ی پایگاه داده دقیقاً چیست؟ صف پیام با چه تنظیماتی ساخته شده؟ چه کسی این دسترسی را به سرویس پرداخت داده؟ چرا در تولید این متغیر محیطی هست ولی در آزمایشی نیست؟ اگر فردا کل محیط را از دست بدهیم، می‌توانیم دوباره آن را بسازیم؟

اگر پاسخ این پرسش‌ها در چند کلیک دستی، چند دستور پراکنده، حافظه‌ی آدم‌ها و مستندات قدیمی پخش شده باشد، زیرساخت خودش تبدیل به منبع خطا می‌شود. همان‌طور که کد بدون نسخه‌بندی و بازبینی خطرناک است، زیرساختی هم که معلوم نیست چه کسی، چه چیزی را، کجا و چرا تغییر داده، دیر یا زود دردسر می‌سازد.

زیرساخت به‌مثابه کد یا Infrastructure as Code، که معمولاً IaC گفته می‌شود، از همین نیاز می‌آید. ایده این است که به‌جای ساختن دستی منابع، وضعیت مطلوب زیرساخت را در فایل‌هایی تعریف کنیم: این پایگاه داده را می‌خواهیم، این شبکه باید وجود داشته باشد، این صف پیام با این تنظیمات ساخته شود، این سرویس این دسترسی را داشته باشد، و این کلاستر Kubernetes با این ویژگی‌ها آماده شود.

وقتی این تعریف‌ها وارد Git می‌شوند، تغییر زیرساخت هم از حالت «کار پنهان در پنل و ترمینال» بیرون می‌آید. می‌توان تغییر را دید، بررسی کرد، درباره‌اش نظر داد، تاریخچه‌اش را فهمید و در بسیاری از موارد دوباره اجرا کرد. هدف این نیست که زیرساخت جادویی شود؛ هدف این است که تصمیم‌های زیرساختی از حافظه‌ی افراد بیرون بیاید و به دارایی قابل نگه‌داری تیم تبدیل شود.

وقتی زیرساخت با کد تعریف می‌شود، محیط‌ها کمتر به حافظه‌ی افراد و کلیک‌های دستی وابسته می‌مانند.

اینجا باید یک مرز مهم را روشن کنیم: IaC فقط «اتوماسیون» نیست. اتوماسیون می‌تواند یک اسکریپت باشد که چند دستور را پشت سر هم اجرا می‌کند. IaC معمولاً یک قدم جلوتر می‌رود و می‌گوید وضعیت مطلوب زیرساخت چیست و ابزار تلاش می‌کند محیط را به آن وضعیت نزدیک کند. البته همه‌ی ابزارها دقیقاً یکسان کار نمی‌کنند، اما در نگاه کلی، تفاوت این است: اسکریپت بیشتر می‌گوید «چه کارهایی انجام بده»، IaC بیشتر تلاش می‌کند بگوید «زیرساخت در نهایت باید چه شکلی باشد».

چند خانواده ابزار در این فضا زیاد دیده می‌شوند:

این ابزارها جای هم نیستند. Terraform معمولاً برای ساخت و مدیریت منابع زیرساختی بیرون یا پیرامون برنامه به کار می‌آید؛ مثلاً شبکه، پایگاه داده، صف یا منابع ابری. Helm و Kustomize بیشتر در فضای Kubernetes کمک می‌کنند برنامه‌ها و منابع داخل کلاستر را تعریف و تنظیم کنیم. Ansible بیشتر به پیکربندی ماشین‌ها و اجرای کارهای عملیاتی نزدیک است. Vault هم مسئله‌ی دیگری را هدف می‌گیرد: رازها و داده‌های حساس را چطور امن، کنترل‌شده و قابل ردیابی نگه داریم.

Helm را می‌توان مثل یک بسته‌بند برای برنامه‌های Kubernetes دید. وقتی یک برنامه فقط یک Deployment ندارد و همراه خودش Service، ConfigMap، Ingress، Secret و چند مقدار قابل تنظیم دارد، نوشتن و نگه‌داری manifestهای خام می‌تواند سخت و تکراری شود. Helm این منابع را در قالب chart بسته‌بندی می‌کند و اجازه می‌دهد برای محیط‌های مختلف، مقدارهای متفاوت بدهیم؛ مثلاً تعداد replica، آدرس سرویس‌ها یا تنظیمات منابع.

برای اینکه ماجرا ملموس‌تر شود، فرض کنید سرویس سفارش به یک پایگاه داده، یک صف پیام، چند متغیر محیطی، چند Secret و یک Deployment روی Kubernetes نیاز دارد. بدون IaC، ممکن است بخشی از این‌ها در پنل ابری ساخته شود، بخشی با دستور دستی، بخشی با فایل‌های پراکنده و بخشی هم در ذهن افراد بماند. با IaC، تلاش می‌کنیم همین نیازها را در فایل‌هایی قابل بازبینی تعریف کنیم؛ فایل‌هایی که تغییراتشان دیده می‌شود و می‌توان درباره‌شان تصمیم گرفت.

اما یک نقطه‌ی حساس در این میان وجود دارد: رازها. رمز اتصال به پایگاه داده، کلید دسترسی به سرویس بیرونی، توکن‌ها و گواهی‌ها نباید مثل تنظیمات معمولی در repository پخش شوند. Kubernetes چیزی به نام Secret دارد، اما این به‌تنهایی پاسخ کامل مدیریت رازها نیست. Secret می‌گوید این داده‌ی حساس باید به شکل یک منبع جدا در کلاستر وجود داشته باشد؛ اما اینکه رازها از کجا بیایند، چه کسی به آن‌ها دسترسی داشته باشد، چطور بچرخند، چطور audit شوند و چطور وارد کلاستر شوند، مسئله‌ی بزرگ‌تری است.

اینجا ابزارهایی مثل Vault وارد می‌شوند. Vault کمک می‌کند رازها در جای متمرکزتر و کنترل‌شده‌تری نگه‌داری شوند، دسترسی‌ها با policy مشخص شوند، بعضی رازها به‌صورت پویا ساخته شوند، و مسیر استفاده از آن‌ها قابل ردیابی‌تر باشد. در عمل، تیم‌ها ممکن است Vault را کنار Kubernetes، External Secrets Operator، Argo CD یا ابزارهای مشابه استفاده کنند تا رازها بدون اینکه مستقیم در Git ذخیره شوند، به برنامه‌ها برسند.

وقتی پای Kubernetes وسط است، یک پرسش عملی‌تر هم پیدا می‌شود: اگر تعریف Deployment و Service و ConfigMap داخل Git است، چه کسی مطمئن شود وضعیت واقعی کلاستر شبیه همین تعریف‌هاست؟ اگر کسی دستی در کلاستر تعداد replica را تغییر داد چه؟ اگر نسخه‌ای که واقعاً در حال اجراست با نسخه‌ی داخل Git فرق داشت چه؟

اینجا GitOps وارد داستان می‌شود.

GitOps را می‌توان این‌طور ساده فهمید: Git منبع حقیقت وضعیت مطلوب سیستم است، و یک ابزار تلاش می‌کند وضعیت واقعی محیط را با چیزی که در Git تعریف شده هماهنگ نگه دارد. یعنی Git فقط محل نگه‌داری کد برنامه نیست؛ دفتر رسمی تصمیم‌های اجرایی و زیرساختی هم می‌شود.

یکی از ابزارهای شناخته‌شده در این فضا Argo CD است. Argo CD معمولاً در کنار Kubernetes استفاده می‌شود و manifestها، Helm chartها یا تنظیمات Kustomize داخل Git را با وضعیت واقعی کلاستر مقایسه می‌کند. اگر اختلافی باشد، می‌تواند آن را نشان دهد و در صورت تنظیم، محیط را دوباره با Git همگام کند.

در GitOps، Git منبع حقیقت وضعیت مطلوب است و ابزاری مثل Argo CD مراقب است کلاستر از آن وضعیت منحرف نشود.

تفاوت IaC و GitOps هم مهم است. IaC بیشتر درباره‌ی این است که منابع و زیرساخت را چگونه با کد تعریف کنیم. GitOps بیشتر درباره‌ی این است که محیط واقعی چگونه با تعریف‌های داخل Git همگام بماند. Argo CD هم یکی از ابزارهایی است که این ایده را، به‌ویژه در Kubernetes، عملی می‌کند.

البته IaC و GitOps هم جادو نیستند. اگر secretها را بد مدیریت کنیم، اگر reviewها سطحی باشند، اگر کسی مستقیم در محیط تولید تغییر بدهد، اگر sync خودکار بدون کنترل روی production فعال شود، یا اگر ساختار repository شلوغ و نامفهوم شود، همین ابزارها هم می‌توانند دردسر تازه بسازند.

چند پرسش خوب پیش از جدی گرفتن IaC و GitOps این‌هاست:

برای من، Infrastructure as Code یعنی زیرساخت را از قلمرو حافظه‌ی افراد و کلیک‌های دستی بیرون بیاوریم و به چیزی تبدیل کنیم که تیم بتواند آن را ببیند، نقد کند، تغییر دهد و دوباره بسازد. GitOps هم یک قدم جلوتر می‌پرسد: حالا که وضعیت مطلوب در Git است، چطور مطمئن شویم محیط واقعی از آن دور نشده است؟ و مدیریت رازها یادآوری می‌کند که قابل بازبینی کردن زیرساخت نباید به قیمت افشا کردن داده‌های حساس تمام شود.

تا اینجا درباره‌ی ساخت، اجرا و نگه‌داری زیرساخت حرف زدیم. اما وقتی محصول رشد می‌کند، پرسش دیگری هم ظاهر می‌شود: آیا همه‌ی مشتری‌ها، سازمان‌ها یا گروه‌های کاربران از یک سیستم مشترک استفاده می‌کنند؟ داده‌ها، تنظیمات و منابع آن‌ها چطور از هم جدا می‌شود؟ اینجا وارد Multi-tenancy می‌شویم.

وقتی یک سیستم باید میزبان چند مشتری باشد​

تا اینجا درباره‌ی طراحی سرویس‌ها، ارتباط میان آن‌ها، اجرای کانتینری، Serverless و زیرساخت قابل بازبینی حرف زدیم. حالا فرض کنیم محصول واقعاً رشد کرده است. دیگر فقط یک تیم یا یک سازمان از آن استفاده نمی‌کند. چند شرکت، چند مدرسه، چند فروشگاه یا چند مشتری سازمانی می‌خواهند از همان سامانه استفاده کنند.

در نگاه اول، شاید ساده به نظر برسد: همان سیستم را برای چند مشتری باز می‌کنیم. اما خیلی زود پرسش‌های جدی‌تر پیدا می‌شوند. داده‌ی هر مشتری کجا نگه‌داری می‌شود؟ کاربران هر مشتری چطور از هم جدا می‌شوند؟ تنظیمات هر مشتری کجا ذخیره می‌شود؟ اگر یک مشتری پرترافیک شد، آیا روی بقیه اثر می‌گذارد؟ اگر یک query اشتباه نوشته شود، آیا ممکن است داده‌ی مشتری دیگری نمایش داده شود؟

اینجاست که مفهوم Multi-tenancy یا معماری چندمستاجری وارد داستان می‌شود. در این مدل، یک سامانه به چند tenant خدمت می‌دهد. tenant می‌تواند یک شرکت، سازمان، تیم، مدرسه، فروشگاه یا هر واحد مستقلی باشد که داده، کاربر، تنظیمات و مرزهای خودش را دارد.

ساده‌ترین راه این است که برای هر مشتری یک نسخه‌ی کامل و جدا از سیستم بالا بیاوریم. این کار از نظر جداسازی ذهنی ساده‌تر است، اما با زیاد شدن مشتری‌ها هزینه‌ی نگه‌داری بالا می‌رود: چند deployment، چند دیتابیس، چند تنظیم، چند migration، چند بکاپ و چند مسیر پایش. از آن طرف، اگر همه‌ی مشتری‌ها را روی یک سیستم کاملاً مشترک بیاوریم، هزینه‌ی عملیاتی کمتر می‌شود، اما خطرها و پیچیدگی‌های تازه‌ای وارد می‌شود.

پس چندمستاجری یک انتخاب صفر و یکی نیست؛ یک طیف است. هرچه اشتراک منابع بیشتر شود، هزینه و عملیات ممکن است ساده‌تر شود، اما مسئولیت ما برای جلوگیری از نشت داده، اثرگذاری مشتری‌ها روی هم و پیچیدگی مجوزها بیشتر می‌شود.

یکی از اولین جاهایی که این تصمیم خودش را نشان می‌دهد، مدل جداسازی داده است. سه مدل رایج‌تر را می‌شود این‌طور دید:

هر مدل، معامله‌ای میان هزینه، جداسازی، امنیت و پیچیدگی عملیاتی است.

هیچ‌کدام از این مدل‌ها «بهترین مطلق» نیستند. اگر داده‌ها بسیار حساس‌اند، تعداد tenantها کم است و نیاز به بکاپ و بازیابی مستقل داریم، دیتابیس جدا می‌تواند منطقی باشد. اگر تعداد tenantها زیاد است و هزینه‌ی عملیاتی باید کنترل شود، جدول مشترک با tenant_id شاید عملی‌تر باشد. گاهی هم مدل ترکیبی داریم: tenantهای معمولی روی منابع مشترک‌اند، اما tenantهای بزرگ یا حساس منابع جدا می‌گیرند.

اما مهم‌ترین سوءبرداشت این است که فکر کنیم چندمستاجری فقط مسئله‌ی دیتابیس است. اضافه کردن tenant_id به جدول‌ها شروع کار است، نه پایان آن. اگر cache با tenant جدا نشود، اگر فایل‌ها در storage مسیر یا مالکیت روشن نداشته باشند، اگر log و metricها tenant-aware نباشند، یا اگر مجوزها درست اعمال نشوند، سیستم هنوز خطرناک است.

در سیستم چندمستاجری، جداسازی داده فقط یکی از لایه‌هاست؛ دسترسی، تنظیمات، منابع، مشاهده‌پذیری و عملیات هم باید tenant-aware باشند.

چندمستاجری را بهتر است در چند لایه ببینیم:

یک مثال ساده بزنیم. فرض کنیم فروشگاه الف و فروشگاه ب هر دو از سامانه‌ی ما استفاده می‌کنند. کاربر فروشگاه الف وارد پنل می‌شود و گزارش سفارش‌ها را می‌بیند. اگر query گزارش فقط بر اساس تاریخ فیلتر کند و tenant را فراموش کند، ممکن است سفارش‌های فروشگاه ب هم در نتیجه بیاید. این فقط یک bug معمولی نیست؛ در سیستم چندمستاجری، چنین خطایی می‌تواند فاجعه‌ی اعتماد و امنیت باشد.

یکی از خطرهای مهم دیگر، مسئله‌ی همسایه‌ی پرمصرف یا noisy neighbor است. وقتی چند tenant روی منابع مشترک اجرا می‌شوند، یک tenant پرترافیک می‌تواند منابع را مصرف کند و کیفیت سرویس tenantهای دیگر را پایین بیاورد. مثلاً یک مشتری گزارش سنگین می‌گیرد، صف پردازش را پر می‌کند یا تعداد زیادی درخواست هم‌زمان می‌فرستد، و مشتری‌های دیگر هم کندی را تجربه می‌کنند.

پس در سیستم چندمستاجری، عدالت منابع هم بخشی از طراحی است. ممکن است به rate limit، سهمیه، صف جدا، pool جدا، منابع اختصاصی برای مشتری‌های بزرگ، یا اولویت‌بندی پردازش نیاز داشته باشیم. این تصمیم‌ها فقط فنی نیستند؛ به قرارداد، مدل درآمدی و سطح سرویس وعده‌داده‌شده به مشتری هم ربط دارند.

انتخاب مدل چندمستاجری باید با چند معیار انجام شود: حساسیت داده، تعداد tenantها، نیاز به سفارشی‌سازی، هزینه‌ی عملیات، الزامات حقوقی، نیاز به بکاپ و بازیابی مستقل، و توان تیم برای نگه‌داری سیستم. تیمی که تازه محصول را ساخته، شاید با مدل ساده‌تری شروع کند و بعد برای tenantهای خاص، جداسازی قوی‌تری اضافه کند. اما اگر از ابتدا داده‌ها بسیار حساس‌اند، ساده‌ترین مدل مشترک شاید انتخاب خطرناکی باشد.

برای من، Multi-tenancy یعنی پذیرفتن یک معامله‌ی مهم: می‌خواهیم تجربه‌ای مشترک و قابل نگه‌داری بسازیم، اما نباید مرز مشتری‌ها را ساده بگیریم. هرجا منابع را مشترک می‌کنیم، باید آگاهانه‌تر درباره‌ی امنیت، دسترسی، مصرف منابع، مشاهده‌پذیری و عملیات فکر کنیم.

تا اینجا گفتیم یک سیستم چندمستاجری چطور داده و منابع چند مشتری را کنار هم نگه می‌دارد. اما همین انتخاب، فصل بعدی را سخت‌تر می‌کند: وقتی ساختار داده تغییر می‌کند، migration دیگر فقط تغییر چند جدول در یک دیتابیس نیست. شاید باید تغییر را روی چند دیتابیس، چند schema یا میلیون‌ها ردیف دارای tenant_id اجرا کنیم. اینجاست که وارد Data Migration می‌شویم.

وقتی داده‌ها هم اسباب‌کشی دارند​

در فصل قبل گفتیم وقتی یک سیستم چندمستاجری می‌شود، داده‌ی چند مشتری، سازمان یا گروه کاربری در کنار هم مدیریت می‌شود. حالا تصور کنیم محصول رشد کرده و یک تغییر ظاهراً ساده از راه می‌رسد: تیم محصول می‌خواهد فیلد آدرس دقیق‌تر شود؛ شهر، استان و کدپستی جدا شوند. یا تیم فنی می‌گوید جدول کاربران باید بازطراحی شود. یا تیم مالی می‌خواهد وضعیت تراکنش‌ها از یک مقدار کلی به چند وضعیت دقیق‌تر تبدیل شود.

در نگاه اول، این‌ها فقط تغییر دیتابیس‌اند: یک ستون اضافه کن، یک جدول بساز، چند داده را جابه‌جا کن، ستون قدیمی را حذف کن. اما در سیستم واقعی، داده زنده است. کاربرها هم‌زمان در حال استفاده‌اند، سرویس‌ها به جدول‌ها وابسته‌اند، گزارش‌ها از داده می‌خوانند، workerها در پس‌زمینه چیزی می‌نویسند، و در سیستم چندمستاجری شاید همین تغییر باید برای چند tenant، schema یا دیتابیس اجرا شود.

اینجاست که Data Migration یا مهاجرت داده وارد داستان می‌شود. مهاجرت داده فقط جابه‌جایی چند ردیف نیست؛ یعنی تغییر دادن ساختار، محل یا معنای داده، بدون اینکه اعتماد سیستم به داده‌ها از بین برود.

یک مثال ساده را در نظر بگیریم. در جدول users قبلاً فقط یک ستون full_name داشتیم. حالا می‌خواهیم آن را به first_name و last_name تبدیل کنیم. اگر در یک حرکت ستون قدیمی را حذف کنیم و کد جدید را منتشر کنیم، ممکن است نسخه‌های قدیمی‌تر کد هنوز full_name بخواهند. ممکن است بعضی داده‌ها درست تفکیک نشوند. ممکن است گزارش‌ها هنوز به ستون قدیمی وابسته باشند. اگر جدول بزرگ باشد، تغییر یک‌باره حتی می‌تواند باعث قفل شدن جدول یا اختلال در سرویس شود.

در مهاجرت یک‌مرحله‌ای، فرض می‌کنیم کد، داده و همه‌ی سرویس‌ها هم‌زمان و بی‌خطا تغییر می‌کنند؛ در سیستم واقعی این فرض معمولاً خطرناک است.

مهاجرت داده شکل‌های مختلفی دارد. گاهی ساختار جدول عوض می‌شود، گاهی خود داده‌ها تبدیل می‌شوند، و گاهی معنای یک مقدار تغییر می‌کند. سخت‌ترین حالت معمولاً همان تغییر معناست، چون خطایش همیشه سریع دیده نمی‌شود.

نکته‌ی مهم این است که migration فقط ALTER TABLE نیست. ممکن است یک migration از نظر دیتابیس ساده باشد، اما از نظر محصولی پیچیده شود. اگر معنای یک وضعیت تغییر کند، باید گزارش‌ها، داشبوردها، APIها، تست‌ها، مستندات و حتی زبان تیم محصول هم با آن تغییر هماهنگ شوند.

راه امن‌تر معمولاً این است که migration را به یک فرایند مرحله‌ای تبدیل کنیم؛ نه یک تغییر ناگهانی. یکی از الگوهای رایج برای این کار، الگوی گسترش، پرکردن و جمع‌کردن است؛ همان چیزی که گاهی با نام Expand → Backfill → Contract شناخته می‌شود.

در مهاجرت مرحله‌ای، ابتدا مسیر جدید را بدون شکستن مسیر قدیمی اضافه می‌کنیم، بعد داده‌ها را آرام‌آرام منتقل می‌کنیم، و فقط وقتی مطمئن شدیم مسیر جدید پایدار است، مسیر قدیمی را حذف می‌کنیم.

در مثال full_name، مسیر امن‌تر می‌تواند این باشد:

1. ستون‌های first_name و last_name را اضافه کنیم، بدون حذف full_name.
2. کد را طوری تغییر دهیم که بتواند با هر دو ساختار کنار بیاید.
3. داده‌های قدیمی را تدریجی و در batchهای کوچک به ساختار جدید منتقل کنیم.
4. مدتی خواندن و نوشتن را پایش کنیم و مطمئن شویم داده‌های جدید درست‌اند.
5. خواندن اصلی را از ساختار جدید انجام دهیم.
6. بعد از اطمینان، مسیر قدیمی را حذف کنیم.

اینجا دوباره بحث سازگاری نسخه‌ها مهم می‌شود. کد جدید باید بتواند با داده‌ی قدیمی کنار بیاید. کد قدیمی هم ممکن است برای مدتی با schema جدید کار کند. اگر چند سرویس داریم که هم‌زمان deploy نمی‌شوند، migration نباید فرض کند همه‌ی آن‌ها هم‌زمان به نسخه‌ی جدید رفته‌اند. اضافه کردن یک ستون معمولاً امن‌تر از rename یا حذف ستون است، چون کد قدیمی معمولاً از اضافه شدن ستون جدید نمی‌شکند؛ اما حذف و تغییرهای مخرب باید با احتیاط و مرحله‌ای انجام شوند.

در سیستم چندمستاجری، migration پیچیده‌تر هم می‌شود. اگر مدل ما جدول مشترک با tenant_id است، migration روی جدول‌های بزرگ و مشترک اجرا می‌شود و باید مراقب فشار روی کل سیستم باشیم. اگر schema جدا برای هر tenant داریم، migration باید روی چند schema اجرا و پایش شود. اگر دیتابیس جدا برای هر tenant داریم، باید بدانیم کدام tenant مهاجرت شده، کدام نشده، و اگر یکی شکست خورد، چه می‌کنیم.

یکی از اشتباه‌های خطرناک این است که migration را در ساعت اوج و بدون مشاهده‌پذیری اجرا کنیم. اگر backfill روی جدول بزرگ بدون محدودیت اجرا شود، می‌تواند دیتابیس را تحت فشار بگذارد. اگر جدول قفل شود، سرویس کند یا از دسترس خارج می‌شود. اگر metric و alert نداشته باشیم، شاید دیر بفهمیم داده‌ها ناقص منتقل شده‌اند.

چند پرسش مهم پیش از اجرای migration:

برای من، Data Migration یعنی پذیرفتن این واقعیت که داده، برخلاف کد، فقط با برگشتن به commit قبلی درست نمی‌شود. داده تاریخچه دارد، معنا دارد، مشتری دارد و خطای آن می‌تواند در گزارش‌ها، تصمیم‌های کسب‌وکار و اعتماد کاربر باقی بماند. پس migration خوب بیشتر از آنکه یک دستور دیتابیس باشد، یک فرایند فنی و عملیاتی است.

وقتی migration را مرحله‌ای، قابل مشاهده و قابل ترمیم طراحی می‌کنیم، در واقع قبول کرده‌ایم که سیستم واقعی همیشه در معرض تغییر و ریسک است. اما آیا کافی است فقط امیدوار باشیم که همه‌چیز درست کار کند؟ یا می‌توانیم آگاهانه سیستم را در برابر خطاها، قطعی‌ها و رفتارهای غیرمنتظره آزمایش کنیم؟ این پرسش ما را به Chaos Engineering می‌رساند.

وقتی خرابی اتفاق بد نیست؛ ناآمادگی بد است​

تا اینجا سیستم ما بزرگ و واقعی‌تر شده است. سرویس‌ها از هم جدا شده‌اند، پیام و صف و رخداد داریم، داده‌ها مهاجرت می‌کنند، زیرساخت با کد مدیریت می‌شود و شاید چند tenant هم روی یک سامانه زندگی می‌کنند. اما یک پرسش هنوز باقی است: وقتی بخشی از این سیستم خراب شود، واقعاً می‌دانیم چه اتفاقی می‌افتد؟ یا فقط امیدواریم که همه‌چیز خوب کار کند؟

خیلی از سیستم‌ها در روزهای عادی سالم به نظر می‌رسند. نمودارها سبز هستند، سرویس‌ها پاسخ می‌دهند و کاربران شکایت خاصی ندارند. اما کافی است یک سرویس کمی کند شود، یک وابستگی بیرونی خطا بدهد، یک نمونه از سرویس سفارش از مدار خارج شود، یا ارتباط با cache برای چند دقیقه قطع شود. آن وقت ممکن است زنجیره‌ای از خطاها شروع شود؛ خطاهایی که تا قبل از حادثه، فقط در ذهن ما «نباید اتفاق می‌افتادند».

Chaos Engineering از همین نقطه شروع می‌شود: به‌جای اینکه فقط منتظر خرابی واقعی بمانیم، خرابی‌های محتمل را در اندازه‌ی کوچک، کنترل‌شده و قابل مشاهده تمرین کنیم تا ضعف‌ها را زودتر پیدا کنیم.

این ایده بیش از همه با Netflix معروف شد. وقتی Netflix روی AWS و معماری ابری توزیع‌شده کار می‌کرد، با واقعیتی روبه‌رو بود که برای خیلی از سیستم‌های امروزی هم آشناست: خرابی ماشین، شبکه، وابستگی بیرونی یا بخشی از زیرساخت اتفاقی عجیب و نادر نیست؛ بخشی از زندگی روزمره‌ی سیستم‌های توزیع‌شده است. Netflix حدود سال ۲۰۱۱ ابزاری به نام Chaos Monkey ساخت؛ ابزاری که به‌صورت کنترل‌شده بعضی instanceها را از مدار خارج می‌کرد تا تیم‌ها مجبور شوند سیستم‌هایی بسازند که با خرابی یک نمونه از پا نیفتند. بعدتر این ایده در قالب ابزارها و روش‌های بیشتری رشد کرد و Chaos Engineering به یک رویکرد مهندسی برای آزمودن تاب‌آوری تبدیل شد.

ایده این نیست که سیستم را بی‌هدف خراب کنیم؛ ایده این است که خرابی‌های قابل انتظار را قبل از روز حادثه، کنترل‌شده تمرین کنیم.

البته خود ایده‌ی تمرین خرابی از هیچ جا ناگهان ظاهر نشد. پیش از این هم تیم‌ها تمرین‌های بازیابی از فاجعه، مانورهای عملیاتی و تست‌های تاب‌آوری داشتند. تفاوت مهم این بود که Netflix این نگاه را در فضای سرویس‌های ابری و توزیع‌شده بسیار ملموس کرد: اگر می‌دانیم خرابی بخشی از واقعیت است، پس باید آن را به شکل کنترل‌شده وارد فرایند یادگیری سیستم کنیم.

اما همین‌جا باید یک سوءبرداشت خطرناک را کنار بگذاریم. Chaos Engineering یعنی «خراب‌کاری تصادفی»؟ نه. یعنی تیمی بدون آمادگی برود production را بلرزاند تا ببیند چه می‌شود؟ قطعاً نه. Chaos Engineering درست، فرضیه‌محور است: اول می‌گوییم انتظار داریم سیستم در یک شرایط مشخص چه رفتاری داشته باشد، بعد یک اختلال محدود و قابل توقف وارد می‌کنیم، و در نهایت نتیجه را با معیارهای روشن می‌سنجیم.

مثلاً فرضیه می‌تواند این باشد: «اگر یکی از نمونه‌های سرویس سفارش از مدار خارج شود، کاربر نباید خطای محسوس ببیند و ترافیک باید به نمونه‌های سالم منتقل شود.» بعد آزمایش را در محدوده‌ای کوچک اجرا می‌کنیم، نرخ خطا، تأخیر، تعداد درخواست‌های ناموفق و رفتار alertها را می‌بینیم، و اگر وضعیت از حد امن خارج شد، آزمایش را متوقف می‌کنیم.

یک آزمایش درست در Chaos Engineering با فرضیه شروع می‌شود، محدوده‌ی اثر دارد، قابل مشاهده است، شرط توقف دارد و در نهایت به یادگیری و اصلاح منجر می‌شود.

چند مفهوم پایه در این مسیر مهم‌اند:

نمونه‌های ساده‌ی آزمایش می‌تواند این‌ها باشد: حذف یک pod در Kubernetes، خاموش کردن یک نمونه از سرویس سفارش، افزایش تأخیر بین سرویس پرداخت و سفارش، قطع موقت دسترسی به cache، کند کردن یک read replica، پر شدن دیسک یک worker، یا خطای موقت در سرویس ارسال پیامک. در سناریوهای پیشرفته‌تر شاید درباره‌ی از دسترس خارج شدن یک availability zone هم فکر کنیم؛ اما شروع عاقلانه معمولاً از آزمایش‌های کوچک‌تر است، نه از بزرگ‌ترین فاجعه‌ی ممکن.

حالا نقد مهم: چرا خیلی از تیم‌ها Chaos Engineering انجام نمی‌دهند؟ همیشه هم از تنبلی یا عقب‌ماندگی نیست. گاهی انجام ندادن آن تصمیم درستی است، چون پیش‌نیازهایش فراهم نیست. اگر metric، log، trace و alert درست نداریم، وارد کردن خطا فقط کور کردن خودمان است. اگر rollback و runbook نداریم، آزمایش خرابی ممکن است خودش حادثه شود. اگر تیم هنوز مالکیت سرویس‌ها را روشن نکرده، معلوم نیست هنگام آزمایش چه کسی باید تصمیم بگیرد.

بنابراین نباید Chaos Engineering را مثل مدال افتخار معرفی کنیم. این کار زمانی ارزشمند است که روی پایه‌های درست سوار شود: مشاهده‌پذیری، مدیریت حادثه، تست‌های معمولی، برنامه‌ی برگشت، مالکیت سرویس و فرهنگ یادگیری بدون مقصرسازی.

خود Chaos Engineering هم اگر بد اجرا شود، چند خطر دارد. یکی اعتماد کاذب است: چند آزمایش ساده موفق می‌شود و تیم فکر می‌کند سیستم واقعاً تاب‌آور است. دیگری آسیب واقعی است: آزمایش بدون محدوده و شرط توقف، خودش outage می‌سازد. خطر سوم هم نمایش مهندسی است؛ یعنی تیم به‌جای حل بدهی‌های معلوم، یک نمایش جذاب از «ما chaos داریم» اجرا می‌کند.

چند پرسش خوب پیش از هر آزمایش:

برای من، Chaos Engineering یعنی صادق بودن با واقعیت سیستم‌های واقعی: خرابی رخ می‌دهد. سؤال این نیست که آیا چیزی خراب می‌شود یا نه؛ سؤال این است که آیا پیش از کاربر و پیش از بحران، رفتار سیستم را در برابر خرابی فهمیده‌ایم یا نه. اگر این کار با فرضیه، محدوده، مشاهده‌پذیری و یادگیری انجام شود، می‌تواند سیستم و تیم را بالغ‌تر کند. اگر بدون این پایه‌ها انجام شود، فقط اسم شیک‌تری برای خطر ساختن است.

تا اینجا بیشتر درباره‌ی سیستم‌های فنی و تاب‌آوری آن‌ها حرف زدیم. اما بعضی پیچیدگی‌ها نه فقط از خرابی فنی، بلکه از فرایندهای انسانی و سازمانی می‌آیند: درخواست‌ها، تأییدها، گردش کارها، نقش‌ها و وضعیت‌هایی که باید بین چند نفر و چند سیستم جابه‌جا شوند. اینجا وارد Business Process Management Systems یا BPMS می‌شویم.

وقتی همه‌چیز قرار نیست با کدنویسی کامل ساخته شود​

بعد از این همه بحث درباره‌ی سرویس‌ها، زیرساخت، مهاجرت داده، چندمستاجری و تاب‌آوری، یک سؤال ساده اما مهم پیش می‌آید: آیا هر نیاز نرم‌افزاری باید با همین وزن مهندسی ساخته شود؟ آیا برای هر فرم داخلی، داشبورد سبک، اتوماسیون کوچک، پنل عملیاتی یا اتصال ساده بین دو ابزار، باید یک پروژه‌ی نرم‌افزاری کامل تعریف کنیم؟

در خیلی از سازمان‌ها، تیم‌های مختلف نیازهای کوچک اما واقعی دارند. تیم فروش یک فرم ثبت سرنخ می‌خواهد. تیم مالی یک گزارش هزینه می‌خواهد. تیم عملیات یک داشبورد وضعیت می‌خواهد. پشتیبانی می‌خواهد وقتی یک رخداد تکراری اتفاق افتاد، پیام خودکار بفرستد. منابع انسانی یک فرم درخواست مرخصی یا فرایند ساده‌ی تأیید می‌خواهد. اگر همه‌ی این درخواست‌ها وارد صف تیم مهندسی شود، کم‌کم تیم فنی به گلوگاه سازمان تبدیل می‌شود.

گاهی مسئله این نیست که تیم مهندسی کند است؛ مسئله این است که هر نیاز کوچک و داخلی هم به همان مسیر سنگین توسعه‌ی نرم‌افزار فرستاده می‌شود.

Low-code و No-code از همین درد تغذیه می‌کنند. وعده‌ی آن‌ها جذاب است: سریع‌تر بساز، کمتر کد بزن، تیم‌های غیرمهندسی را توانمندتر کن، و همه‌چیز را برای یک فرم، داشبورد یا اتوماسیون کوچک از صفر نساز. اما همین‌جا باید مراقب باشیم؛ این بخش قرار نیست تبلیغ ابزار باشد. Low-code/No-code هم می‌تواند کمک کند، هم می‌تواند در بلندمدت سیستم را کندتر، مبهم‌تر و شکننده‌تر کند.

ایده‌ی ساختن ابزار بدون کدنویسی کامل، چیز تازه‌ای نیست. سال‌ها قبل از اینکه اصطلاح Low-code/No-code مد شود، آدم‌ها با صفحه‌گسترده‌ها، Microsoft Access، ماکروها، فرم‌سازها و ابزارهای گزارش‌گیری تلاش می‌کردند کارهای روزمره‌ی خودشان را بدون ساختن یک نرم‌افزار کامل جلو ببرند. یعنی میل به اینکه «کاربر غیرمهندس هم بتواند چیزی بسازد» قدیمی‌تر از اسم‌های امروزی است.

بعدتر، ابزارهای سریع‌ساز برنامه، فرم‌سازها، ابزارهای اتوماسیون، پلتفرم‌های ساخت اپلیکیشن داخلی و سکوهای اتصال بین سرویس‌ها جدی‌تر شدند. امروز این فضا گسترده‌تر شده است: ابزارهایی مثل Retool، Airtable، AppSheet، Power Apps، Zapier، Make و n8n هرکدام از زاویه‌ای کمک می‌کنند فرم، داشبورد، پنل داخلی، جریان خودکار یا اتصال میان سرویس‌ها سریع‌تر ساخته شود.

n8n مثال خوبی است، چون نشان می‌دهد Low-code/No-code فقط فرم‌ساز نیست. n8n بیشتر در دسته‌ی اتوماسیون جریان کار قرار می‌گیرد: می‌توانیم چند سرویس را به هم وصل کنیم، وبهوک بگیریم، بر اساس زمان‌بندی کاری اجرا کنیم، داده را از یک ابزار به ابزار دیگر بفرستیم، پیام Telegram یا Slack ارسال کنیم، یا یک API داخلی را صدا بزنیم. مثلاً وقتی یک فرم پر شد، داده وارد CRM شود، یک پیام برای تیم فروش برود، یک وبهوک داخلی صدا زده شود، و در پایان ایمیل تأیید ارسال شود.

این‌ها واقعاً می‌توانند مفید باشند. برای ساخت نمونه‌ی اولیه، ابزار داخلی کم‌ریسک، اتوماسیون‌های سبک، داشبوردهای عملیاتی و کارهای تکراری، Low-code/No-code می‌تواند سرعت سازمان را بالا ببرد. تیم مهندسی هم به جای ساختن ده‌ها ابزار کوچک و کم‌ریسک، روی هسته‌ی محصول، معماری و مسائل سخت‌تر تمرکز می‌کند.

اما نیمه‌ی تاریک ماجرا همین‌جاست. چیزی که امروز به اسم میان‌بر ساخته می‌شود، فردا ممکن است تبدیل شود به زیرساخت نامرئی سازمان. یک جریان ساده در n8n، یک فرم در Airtable، یک پنل در Retool یا چند اتوماسیون در Zapier اول کار کمک می‌کند؛ اما کم‌کم همان‌ها می‌شوند مسیر اصلی ثبت درخواست، ارسال پیام به مشتری، تأیید مالی، تغییر وضعیت سفارش، گزارش مدیریتی یا اتصال بین دو سیستم مهم. آن وقت دیگر با یک ابزار ساده طرف نیستیم؛ با یک سیستم تولیدی طرفیم که فقط مثل سیستم تولیدی با آن رفتار نشده است.

روی سطح، چند جریان سریع و تمیز می‌بینیم؛ زیر سطح، ممکن است منطق پخش‌شده، مالکیت مبهم، دسترسی‌های زیاد، نبود تست و بدهی نامرئی شکل گرفته باشد.

نقد ما اصل این ابزارها نیست؛ نقد ما استفاده‌ی بی‌مالکیت و بی‌چرخه‌ی عمر از آن‌هاست. نقد تند اینجاست: این ابزارها اغلب کار را از تیم مهندسی کم نمی‌کنند؛ کار را از جلوی چشم تیم مهندسی پنهان می‌کنند. در کوتاه‌مدت صف مهندسی را دور می‌زنند، اما در بلندمدت صف تازه‌ای می‌سازند: صف فهمیدن اینکه چه کسی کجا چه چیزی ساخته، چرا خراب شده، به چه داده‌ای دسترسی دارد، کدام جریان منطق اصلی کسب‌وکار را اجرا می‌کند، و اگر ابزار از کار افتاد چه کسی باید پاسخ‌گو باشد.

مشکل Low-code/No-code این نیست که «کد کم دارد»؛ مشکل وقتی شروع می‌شود که «مسئولیت مهندسی» هم کم‌کم حذف شود. هر چیزی که در مسیر واقعی کسب‌وکار قرار می‌گیرد، نرم‌افزار است؛ حتی اگر با کشیدن چند گره ساخته شده باشد. اگر آن چیز مشتری را تحت تأثیر قرار می‌دهد، داده‌ی حساس می‌خواند، پول جابه‌جا می‌کند، وضعیت سفارش را تغییر می‌دهد یا فرایند روزانه‌ی تیمی را پیش می‌برد، دیگر نمی‌توان با آن مثل یک فایل موقت برخورد کرد.

در n8n و ابزارهای مشابه، خطر اصلی این نیست که جریان ساخته‌ایم؛ خطر این است که جریان تبدیل به منطق کسب‌وکار شده، اما هنوز با آن مثل یک آزمایش کوچک برخورد می‌کنیم. این جریان‌ها معمولاً مجوز و اطلاعات اتصال دارند، به APIهای مختلف وصل می‌شوند، داده جابه‌جا می‌کنند و گاهی تصمیم‌های مهم می‌گیرند. اگر مالکیت، کنترل دسترسی، نسخه‌بندی، پشتیبان‌گیری، پایش و هشدار نداشته باشند، یک گره کوچک، یک مجوز منقضی‌شده یا یک تغییر در API بیرونی می‌تواند یک فرایند مهم را بخواباند.

پس اگر قرار است Low-code/No-code وارد سازمان شود، باید با حاکمیت و مرز روشن وارد شود. باید معلوم باشد چه کسی مالک هر جریان یا ابزار است، چه داده‌ای خوانده می‌شود، چه دسترسی‌هایی داده شده، تغییرات چطور بازبینی می‌شوند، خطاها کجا دیده می‌شوند، و چه زمانی یک ابزار داخلی باید از حالت موقت خارج شود و به سیستم جدی‌تر تبدیل شود.

سرعت خوب است، اما بدون کنترل می‌تواند خطرناک شود. ابزارهای کم‌کدنویسی هم به مالکیت، دسترسی، بازبینی، نسخه‌بندی، پایش و پشتیبانی نیاز دارند.

Low-code/No-code برای همه‌چیز بد نیست؛ اتفاقاً اگر درست استفاده شود، بسیار مفید است. برای ساخت نمونه‌ی اولیه، فرم‌های داخلی کم‌ریسک، داشبوردهای سبک، اتوماسیون‌های ساده و ابزارهای عملیاتی کوچک می‌تواند انتخاب خوبی باشد. اما هرچه ابزار به داده‌ی حساس، تراکنش مالی، منطق اصلی محصول، مشتری واقعی یا عملیات حیاتی نزدیک‌تر شود، باید سخت‌گیرتر شویم. آنجا دیگر سرعت اولیه کافی نیست؛ چرخه‌ی عمر مهم است.

این نگاه، ما را از یک سوءبرداشت دور می‌کند: Low-code/No-code جایگزین مهندسی نرم‌افزار نیست؛ فقط بعضی شکل‌های ساخت نرم‌افزار را برای بعضی مسئله‌ها سریع‌تر و در دسترس‌تر می‌کند. اگر مسئله کوچک، داخلی، کم‌ریسک و قابل جایگزینی است، این ابزارها می‌توانند عالی باشند. اگر مسئله حیاتی، حساس، پیچیده و بلندمدت است، باید همان سطحی از فکر مهندسی را وارد کنیم که برای هر سیستم مهم دیگری لازم داریم.

برای من، Low-code/No-code نه ناجی است و نه دشمن. یک ابزار است؛ ابزاری که وقتی برای مسئله‌ی درست، با مالکیت روشن و مرز مشخص استفاده شود، سرعت می‌سازد. اما وقتی جای معماری، مالکیت و چرخه‌ی عمر نرم‌افزار را بگیرد، در بلندمدت همان چیزی را تولید می‌کند که قرار بود حل کند: کندی، آشفتگی و وابستگی.

اینجا پل بخش بعد شکل می‌گیرد. Low-code/No-code خانواده‌ی وسیعی از ابزارهاست؛ از فرم و داشبورد تا اتوماسیون و اتصال بین سرویس‌ها. اما وقتی مسئله از چند اتصال ساده فراتر می‌رود و تبدیل می‌شود به فرایند رسمی سازمانی با نقش‌ها، وضعیت‌ها، تأییدها، زمان‌بندی‌ها، گزارش مدیریتی و چرخه‌ی عمر روشن، وارد دنیای BPMS می‌شویم.

وقتی کار فقط کد نیست، فرایند هم هست​

در بخش قبل گفتیم Low-code و No-code می‌توانند برای فرم‌ها، داشبوردها، اتوماسیون‌های سبک و ابزارهای داخلی مفید باشند؛ اما همان‌جا هم دیدیم که اگر این ابزارها بدون مالکیت و مرز روشن رشد کنند، آرام‌آرام تبدیل می‌شوند به زیرساخت نامرئی سازمان. حالا یک قدم جلوتر می‌رویم. فرض کنیم مسئله دیگر فقط یک فرم یا یک جریان ساده نیست؛ مسئله خودِ فرایند کسب‌وکار است.

تفاوت BPMS با یک جریان ساده این است که BPMS بیشتر درباره‌ی زندگی یک پرونده در طول زمان است؛ نه فقط اجرای چند عمل پشت سر هم. یک پرونده ممکن است میان چند نقش انسانی، چند تصمیم، چند وضعیت، چند سیستم و چند زمان‌بندی حرکت کند.

یک مثال ساده را در نظر بگیریم: مرجوعی کالا. اول کار شاید فقط یک فرم باشد. مشتری درخواست می‌دهد، پشتیبانی بررسی می‌کند و نتیجه را اعلام می‌کند. اما بعد سازمان رشد می‌کند و فرایند شاخه پیدا می‌کند. اگر مبلغ کالا زیاد بود، مدیر باید تأیید کند. اگر دلیل مرجوعی خرابی بود، تیم کنترل کیفیت باید نظر بدهد. اگر تأیید شد، تیم مالی باید بازپرداخت انجام دهد. اگر سه روز گذشت و اقدامی نشد، باید هشدار بخورد. اگر رد شد، دلیل رد باید ثبت شود. اگر تأیید شد، باید به سیستم انبار یا مالی پیام برود.

اینجا دیگر با یک فرم ساده طرف نیستیم. با کاری طرفیم که بین چند نقش انسانی، چند تصمیم، چند وضعیت، چند سیستم و چند زمان‌بندی حرکت می‌کند. اگر این مسیر در ایمیل، اکسل، پیام‌رسان، تماس تلفنی، چند اسکریپت و حافظه‌ی آدم‌ها پخش شود، بعد از مدتی هیچ‌کس دقیق نمی‌داند هر درخواست کجاست، چرا گیر کرده، چه کسی باید اقدام کند و قانون تصمیم دقیقاً کجا تعریف شده است.

وقتی یک فرایند واحد در ابزارهای مختلف پخش شود، دیدن وضعیت، مسئول مرحله‌ی بعد و دلیل توقف کار سخت می‌شود.

BPMS یا سامانه‌ی مدیریت فرایندهای کسب‌وکار، از همین درد شروع می‌شود. ایده این است که فرایندهای مهم فقط در ذهن آدم‌ها، ایمیل‌ها، فایل‌های پراکنده و کدهای نامنظم زندگی نکنند؛ بلکه مدل‌سازی، اجرا، پایش و اصلاح شوند. BPMS تلاش می‌کند جریان کار را به چیزی تبدیل کند که بتوانیم آن را ببینیم، درباره‌اش حرف بزنیم، وضعیتش را بفهمیم و تغییرش را کنترل کنیم.

میل به مدیریت فرایندها چیز تازه‌ای نیست. سازمان‌ها همیشه فرم، ارجاع، تأیید، پرونده و گردش کار داشته‌اند. در دنیای نرم‌افزار هم از سال‌ها قبل سیستم‌های جریان کار، موتورهای قوانین، ابزارهای BPM و زبان‌های مدل‌سازی فرایند شکل گرفتند. استانداردهایی مثل BPMN کمک کردند فرایندها به شکل نمودارهایی مدل شوند که هم برای تحلیل‌گر کسب‌وکار قابل فهم باشند، هم برای تیم فنی قابل تبدیل به اجرا یا پیاده‌سازی. امروز ابزارهایی مثل Camunda، Flowable، Bonita و ابزارهای مشابه تلاش می‌کنند همین ایده را در سیستم‌های واقعی اجراپذیرتر کنند.

اما BPMS فقط کشیدن فلوچارت نیست. اگر فقط نمودار بکشیم و بعد همه‌چیز همچنان در ایمیل و کدهای پراکنده اجرا شود، مسئله حل نشده است. BPMS وقتی معنا دارد که فرایند بتواند وضعیت داشته باشد، در مرحله‌ای منتظر بماند، به نقش مشخصی وظیفه بدهد، بر اساس تصمیم مسیر عوض کند، به سرویس بیرونی پیام بدهد، زمان‌سنج و هشدار داشته باشد و قابل پایش باشد.

در همان مثال مرجوعی کالا، می‌توانیم مسیر را روشن‌تر کنیم: درخواست ثبت می‌شود، پشتیبانی بررسی اولیه انجام می‌دهد، اگر نیاز به تأیید داشت مدیر وارد می‌شود، اگر تأیید شد تیم مالی اقدام می‌کند و در پایان وضعیت درخواست بسته می‌شود. در هر لحظه معلوم است درخواست در چه وضعیتی است، مسئول مرحله‌ی بعد کیست و چرا از یک مسیر خاص عبور کرده است.

در BPMS، فرایند فقط چند دستور پشت سر هم نیست؛ یک مسیر دارای وضعیت، نقش، تصمیم و قابل پیگیری است.

مزیت اصلی BPMS این نیست که کد را حذف می‌کند. مزیت اصلی این است که فرایند را به یک موجود قابل مشاهده و قابل بحث تبدیل می‌کند. آدم محصول، عملیات، حقوقی، مالی و فنی می‌توانند درباره‌ی یک مدل مشترک حرف بزنند. می‌توانند ببینند گلوگاه کجاست، چه مرحله‌ای زیاد طول می‌کشد، کدام تصمیم‌ها زیاد رد می‌شوند، و کجا باید نقش، قانون یا مسیر فرایند تغییر کند.

اما حالا نوبت نقد جدی است. BPMS نباید تبدیل شود به جایی که منطق اصلی محصول در آن دفن می‌شود. این خطر واقعی است. چون ظاهر BPMS معمولاً شفاف و فریبنده است: چند نمودار، چند کار، چند فرم، چند تصمیم و چند اتصال. اما اگر مراقب نباشیم، همان منطق مهمی که باید در سرویس‌های قابل تست، قابل مشاهده و دامنه‌محور باشد، در میان نمودارها، کارهای اسکریپتی، قانون‌های پراکنده و اتصال‌های پنهان دفن می‌شود.

مشکل BPMS این نیست که فرایند را مدل می‌کند؛ مشکل وقتی شروع می‌شود که مدل فرایند جای طراحی دامنه و معماری سیستم را بگیرد. اگر قواعد اصلی محصول، محاسبات حساس، تصمیم‌های امنیتی، منطق مالی یا تغییرات مهم وضعیت را بی‌حساب داخل BPMS ببریم، بعد از مدتی سیستم نه ساده‌تر، که سخت‌تر از کد معمولی قابل فهم و تغییر می‌شود.

گاهی BPMS پیچیدگی را از کد بیرون نمی‌کشد؛ فقط همان پیچیدگی را در نمودارها، کارها و اتصال‌های پنهان قایم می‌کند.

فرایندها به مرور شاخه و شرط پیدا می‌کنند. یک استثنا برای مشتری مهم اضافه می‌شود، بعد یک مسیر ویژه برای قراردادهای بزرگ، بعد یک قانون موقت برای تیم مالی، بعد یک اسکریپت برای اصلاح داده، بعد یک اتصال به CRM، بعد یک اتصال به سرویس پرداخت. بعد از مدتی نموداری که قرار بود شفاف‌کننده باشد، خودش تبدیل می‌شود به جنگلی از فلش‌ها و شرط‌ها. تغییر ساده نیازمند فهم چند مدل، چند نقش، چند فرم، چند اتصال بیرونی و چند قانون پنهان می‌شود.

پس مرز سالم این است: BPMS بهتر است ارکسترکننده‌ی فرایند باشد، نه مالک همه‌ی منطق کسب‌وکار. اگر قرار است اعتبار مالی مشتری محاسبه شود، موجودی کیف پول تغییر کند، سیاست امنیتی حساس اعمال شود یا تصمیمی با اثر مالی جدی گرفته شود، بهتر است این منطق در سرویس‌های دامنه‌محور، قابل تست و قابل مشاهده بماند. BPMS می‌تواند آن سرویس‌ها را صدا بزند، مسیر را هماهنگ کند و وضعیت فرایند را نگه دارد، اما نباید بی‌دلیل جای آن‌ها را بگیرد.

برای فرایندهای ساده، از روز اول BPMS لازم نیست. اگر یک فرم داخلی، یک تأیید ساده یا یک اتوماسیون کم‌ریسک داریم، شاید همان ابزارهای ساده‌تر بخش قبل کافی باشند. BPMS وقتی ارزش پیدا می‌کند که فرایند واقعاً طولانی، چندنقشی، تغییرپذیر، حساس به زمان و نیازمند حسابرسی باشد. در غیر این صورت، ممکن است ابزار سنگینی وارد کنیم که خودِ ابزار از مسئله بزرگ‌تر شود.

برای من، BPMS یعنی پذیرفتن اینکه در بعضی سیستم‌ها، خودِ فرایند به اندازه‌ی کد مهم است. باید بدانیم کار کجاست، دست کیست، چرا متوقف شده و با چه قانونی جلو می‌رود. اما BPMS هم مثل Low-code/No-code قرار نیست جای فکر مهندسی را بگیرد. وقتی درست استفاده شود، فرایند را شفاف و قابل پایش می‌کند. وقتی بد استفاده شود، پیچیدگی را در نمودارها پنهان می‌کند و به سیستم ظاهراً تصویری اما عملاً سخت‌فهم می‌رسیم.

تا اینجا درباره‌ی ابزارهایی حرف زدیم که ساخت نرم‌افزار، عملیات، فرایند و اتوماسیون را تغییر می‌دهند. اما موج تازه‌تری هم وارد مهندسی نرم‌افزار شده است: هوش مصنوعی. حالا سؤال این است که آیا هوش مصنوعی می‌تواند خود فرایند ساخت نرم‌افزار را تغییر دهد؟ اینجا وارد AI4SE می‌شویم؛ یعنی استفاده از هوش مصنوعی برای کمک به مهندسی نرم‌افزار.

وقتی هوش مصنوعی وارد کارگاه مهندسی نرم‌افزار می‌شود​

حتی اگر معماری، زیرساخت و فرایندها را بهتر کنیم، خود کار روزمره‌ی مهندسی نرم‌افزار هنوز سنگین است. کد بیشتر شده، درخواست‌های ادغام یا Pull Requestها بزرگ‌تر شده‌اند، سرویس‌ها به هم وابسته‌تر شده‌اند، مستندات زود کهنه می‌شوند، تست‌ها باید به‌روز بمانند، بازآرایی کد یا refactor خطر شکستن رفتار دارد، و بازبینی تغییرات وقت و دقت زیادی می‌خواهد. حتی اگر تیم خوبی داشته باشیم، بخشی از کارهای روزانه تکراری، فرساینده و مستعد خطای انسانی‌اند.

اینجا AI4SE وارد می‌شود. AI4SE یعنی استفاده از هوش مصنوعی برای کمک به فعالیت‌های مهندسی نرم‌افزار؛ نه حذف مهندسی نرم‌افزار. هوش مصنوعی می‌تواند کنار تیم بنشیند، بعضی کارها را سریع‌تر کند، بعضی مسیرهای فهم را کوتاه‌تر کند و بعضی خطاها را زودتر به چشم بیاورد. اما تصمیم، مالکیت و مسئولیت همچنان با تیم مهندسی است.

این مسیر از هیچ‌جا ناگهان با ChatGPT شروع نشد. قبل از موج مدل‌های زبانی بزرگ، سال‌ها ابزارهای تحلیل ایستا، ابزارهای سبک بررسی کد، جست‌وجوی کد، تکمیل خودکار، پیشنهاد بازآرایی، تشخیص خطا و تولید تست وجود داشتند. بخشی از آن‌ها قاعده‌محور بودند، بخشی از تکنیک‌های برنامه‌کاوی و یادگیری ماشین استفاده می‌کردند، و بخشی هم در محیط‌های توسعه به شکل پیشنهادهای محدود دیده می‌شدند.

بعدتر با رشد یادگیری عمیق و مدل‌های آموزش‌دیده روی کد، کمک‌های هوشمندتر ممکن شد. برای خیلی از توسعه‌دهنده‌ها، GitHub Copilot یک نقطه‌ی عطف بود؛ ابزاری که در ۲۰۲۱ به‌عنوان یک «همکار برنامه‌نویس هوشمند» معرفی شد و تجربه‌ی تولید و تکمیل کد با مدل زبانی را وارد کار روزمره‌ی توسعه‌دهندگان کرد. اما موج بعدی فقط تکمیل خودکار نبود. با رشد مدل‌های زبانی بزرگ، مسئله از ادامه دادن چند خط کد به فهمیدن شرح مسئله، خواندن چند فایل، پیشنهاد وصله، نوشتن تست، توضیح تغییر و حتی اجرای چند گام روی مخزن کد نزدیک شد.

هوش مصنوعی می‌تواند کنار مهندس باشد؛ برای پیشنهاد، توضیح، بررسی و یادآوری. اما جای تصمیم مهندسی، مالکیت و فهم سیستم را نمی‌گیرد.

کاربردهای AI4SE فقط به تولید کد محدود نیست. گاهی ارزش آن در فهمیدن کد موجود است: خلاصه کردن یک فایل پیچیده، توضیح مسیر اجرای یک قابلیت، یا پیدا کردن ارتباط چند کلاس و سرویس. گاهی در تست کمک می‌کند: پیشنهاد حالت‌های مرزی، ساخت داده‌ی آزمایشی یا یادآوری سناریوهایی که از قلم افتاده‌اند. گاهی در بازبینی کد مفید است: خلاصه کردن درخواست ادغام، برجسته کردن تغییرهای پرریسک، پیشنهاد تست، یا پیدا کردن ناسازگاری با قرارداد API. گاهی هم در مستندسازی و عیب‌یابی کمک می‌کند: نوشتن پیش‌نویس مستندات، خلاصه کردن لاگ‌ها، دسته‌بندی خطاها یا کوتاه کردن مسیر بررسی حادثه.

اما هرچه از «تولید چند خط کد» به «تصمیم مهندسی» نزدیک می‌شویم، کیفیت زمینه مهم‌تر می‌شود. یک مدل اگر فقط تغییرات کد را ببیند، شاید بتواند ظاهر تغییر را توضیح دهد؛ اما نمی‌تواند همیشه بفهمد این تغییر با نیت شرح مسئله، قرارداد API، معماری سرویس، تست‌های موجود، محدودیت‌های دامنه و تجربه‌ی کاربر سازگار است یا نه. در کارهای جدی، مدل فقط به دستور خوب نیاز ندارد؛ به زمینه‌ی خوب نیاز دارد.

این نکته مخصوصاً در بازبینی کد پررنگ است. بازبینی خوب فقط خواندن تغییرات کد نیست. بازبینی یعنی فهمیدن اینکه چرا این تغییر انجام شده، روی چه رفتاری اثر می‌گذارد، چه قراردادی را تغییر می‌دهد، کدام تست باید اضافه شود، چه چیزی ممکن است در سرویس دیگری بشکند و آیا این تغییر با مسیر بلندمدت سیستم سازگار است یا نه.

هوش مصنوعی وقتی بهتر بازبینی می‌کند که فقط تغییرات کد را نبیند؛ بلکه شرح مسئله، تست‌ها، مستندات، قراردادها، معماری و لاگ‌ها هم بخشی از زمینه باشند.

برای همین، بازبین هوشمند خوب باید بیشتر از یک تولیدکننده‌ی نظر باشد. باید بتواند نیت تغییر را بفهمد، سؤال‌های درست بپرسد، جاهایی را که نیاز به تست دارند برجسته کند، و اگر زمینه کافی نیست، با اعتمادبه‌نفس بی‌جا حکم ندهد. حتی در بهترین حالت هم نقش آن کمک به بازبین انسانی است، نه جایگزینی کامل او.

در تولید تست هم همین مرز وجود دارد. هوش مصنوعی می‌تواند حالت آزمایشی پیشنهاد بدهد، اما تست خوب فقط زیاد بودن تعداد تست‌ها نیست. تست خوب باید رفتار مهم را تثبیت کند، حالت مرزی واقعی را پوشش دهد و نسبت به بازآرایی‌های بی‌اثر شکننده نباشد. اگر هوش مصنوعی تست‌هایی بسازد که فقط جزئیات پیاده‌سازی را بررسی می‌کنند، ممکن است تعداد تست‌ها زیاد شود، اما اعتماد ما به تغییر بیشتر نشود. حتی بدتر، ممکن است بازآرایی‌های خوب را سخت‌تر کند، چون تست‌ها به جای رفتار، به شکل داخلی کد چسبیده‌اند.

هدف تست، افزایش اعتماد به تغییر است؛ نه فقط افزایش تعداد فایل‌های تست. این همان جایی است که قضاوت مهندسی مهم می‌شود. مدل می‌تواند پیشنهاد بدهد، اما تیم باید تشخیص دهد آیا این تست واقعاً رفتار مهم را پوشش می‌دهد یا فقط خروجی ظاهراً قانع‌کننده تولید کرده است.

حالا نقد اصلی بخش: AI4SE وقتی خطرناک می‌شود که سازمان‌ها سرعت تولید خروجی را با کیفیت مهندسی اشتباه بگیرند. مدل می‌تواند سریع کد بنویسد، اما سریع‌تر نوشتن کد لزوماً یعنی سریع‌تر رسیدن به نرم‌افزار قابل نگه‌داری نیست. ممکن است خروجی زیاد شود، اما بازبینی سخت‌تر شود. ممکن است کد بیشتری تولید شود، اما کسی عمیقاً مالک آن نباشد. ممکن است تست بیشتری ساخته شود، اما رفتار مهم پوشش داده نشود. ممکن است مستندات روان‌تر شوند، اما دقیق نباشند.

روی سطح، تولید کد، تست و مستندات سریع‌تر می‌شود؛ زیر سطح، اگر مالکیت و بازبینی نباشد، بدهی نگه‌داری و ابهام سیستم بیشتر می‌شود.

خطر AI4SE فقط این نیست که مدل اشتباه می‌کند. خطر بزرگ‌تر این است که مدل با اعتمادبه‌نفس اشتباه می‌کند و ما هم از خستگی، فشار زمانی یا جذابیت سرعت، آن را می‌پذیریم. خروجی مدل معمولاً خوش‌ساخت و قانع‌کننده است؛ همین باعث می‌شود خطاهایش دیرتر دیده شود. کدی که با اطمینان نوشته شده، تستی که نام خوبی دارد، یا مستندی که روان است، الزاماً درست نیست.

هوش مصنوعی می‌تواند تولید کد را ارزان‌تر کند، اما اگر فهم سیستم گران‌تر شود، تیم در مجموع کندتر شده است. این جمله برای من مرکز نقد AI4SE است. اگر هر قابلیت با سرعت بیشتری کد تولید کند، اما بازبینی، نگه‌داری، عیب‌یابی و فهم تغییر سخت‌تر شود، ما فقط بدهی فنی را سریع‌تر تولید کرده‌ایم.

پس مرز سالم چیست؟ هوش مصنوعی برای کارهای کمکی، تکراری، توضیحی و اکتشافی بسیار مفید است؛ جایی که انسان هنوز تصمیم نهایی را می‌گیرد. خلاصه کردن درخواست ادغام، پیشنهاد حالت‌های آزمایشی، تولید پیش‌نویس مستندات، توضیح کد قدیمی، کمک به جست‌وجو در مخزن کد، یا ساخت نمونه‌ی اولیه می‌تواند عالی باشد. اما تصمیم‌های حساس معماری، امنیت، داده، رفتار دامنه و تغییرات پرریسک نباید فقط به خروجی مدل سپرده شوند.

هوش مصنوعی نمی‌تواند جای خالی معماری نامفهوم، تست‌های بد، مستندات فرسوده و مالکیت مبهم را معجزه‌وار پر کند؛ گاهی فقط آن‌ها را سریع‌تر تکثیر می‌کند. اگر مخزن کد بی‌نظم است، اگر قراردادها روشن نیستند، اگر تست‌ها شکننده‌اند، اگر شرح مسئله‌ها مبهم‌اند، مدل هم بر همان ابهام سوار می‌شود و خروجی‌هایی می‌دهد که شاید زیبا باشند، اما الزاماً قابل اتکا نیستند.

برای من، AI4SE یعنی آوردن یک دستیار قدرتمند به کارگاه مهندسی نرم‌افزار. این دستیار می‌تواند سریع بخواند، سریع پیشنهاد بدهد، سریع خلاصه کند و سریع پیش‌نویس بسازد. اما نرم‌افزار خوب فقط از سرعت ساخته نمی‌شود. نرم‌افزار خوب به فهم، مالکیت، بازبینی، تست، طراحی و تصمیم‌گیری مسئولانه نیاز دارد. هوش مصنوعی اگر این‌ها را تقویت کند، ارزشمند است؛ اگر جای آن‌ها بنشیند، خطرناک است.

تا اینجا گفتیم هوش مصنوعی چطور می‌تواند به مهندسی نرم‌افزار کمک کند. اما سؤال برعکس هم وجود دارد: وقتی خود محصول ما مبتنی بر هوش مصنوعی است، چطور باید آن را مهندسی کنیم؟ مدل‌ها رفتار کاملاً قطعی ندارند، داده و دستور و ارزیابی بخشی از سیستم می‌شوند، و رفتار خروجی همیشه مثل کد معمولی قابل پیش‌بینی نیست. اینجا وارد SE4AI می‌شویم: مهندسی نرم‌افزار برای سیستم‌های هوش مصنوعی.

وقتی خود هوش مصنوعی هم به مهندسی نیاز دارد​

در بخش قبل گفتیم هوش مصنوعی چطور می‌تواند به مهندسی نرم‌افزار کمک کند: در فهم کد، نوشتن تست، بازبینی، مستندسازی و عیب‌یابی. حالا سؤال را برعکس می‌کنیم. اگر خودِ محصول ما مبتنی بر هوش مصنوعی باشد چه؟ اگر قابلیت اصلی سیستم نه فقط چند خط کد، بلکه یک مدل، دستور مدل، داده، بازیابی دانش، ارزیابی و سیاست محصولی باشد، مهندسی نرم‌افزار چه نقشی دارد؟

تصور کنیم تیمی می‌خواهد یک قابلیت هوشمند به محصول اضافه کند: چت‌بات پشتیبانی، سیستم پیشنهاددهنده، تشخیص تقلب، خلاصه‌سازی تیکت‌ها، تحلیل احساسات پیام‌های کاربران، جست‌وجوی هوشمند، یا یک قابلیت مبتنی بر مدل زبانی بزرگ برای تولید پاسخ. در دمو همه‌چیز جذاب است. چند مثال خوب جواب می‌گیرند، تیم محصول هیجان‌زده می‌شود و همه حس می‌کنند «فقط کافی است مدل را صدا بزنیم».

اما محصول واقعی با دمو فرق دارد. ورودی‌ها تمیز و قابل پیش‌بینی نیستند. کاربران سؤال‌های عجیب می‌پرسند. داده‌ی زمینه ناقص است. خروجی مدل گاهی غلط اما قانع‌کننده است. دستورهای مدل تغییر می‌کنند. نسخه‌ی مدل عوض می‌شود. معیار کیفیت همیشه یک عدد ساده نیست. گاهی پاسخ از نظر زبانی خوب است، اما از نظر محصولی، حقوقی، امنیتی یا اخلاقی قابل قبول نیست. اینجا روشن می‌شود که سیستم مبتنی بر هوش مصنوعی فقط مدل نیست؛ یک سیستم نرم‌افزاری کامل است.

مرز این بخش با بخش قبل و بعدی مهم است. AI4SE می‌پرسید: هوش مصنوعی چطور به کارهای مهندسی نرم‌افزار کمک می‌کند؟ SE4AI می‌پرسد: وقتی نرم‌افزارمان هوش مصنوعی دارد، چطور آن را مثل یک سیستم مهندسی‌شده، قابل تست، قابل کنترل و قابل اعتماد بسازیم؟ MLOps که بخش بعدی است، بیشتر روی چرخه‌ی عملیاتی مدل‌ها تمرکز می‌کند: داده، آموزش، نسخه‌بندی مدل، استقرار، پایش، رانش و بازآموزی.

در نرم‌افزار سنتی، بخش زیادی از رفتار سیستم از کدی می‌آمد که خودمان نوشته بودیم. اگر ورودی مشخصی می‌دادیم، انتظار خروجی مشخصی داشتیم. البته باگ همیشه وجود داشت، اما رفتار اصلی سیستم از منطق صریح کد می‌آمد. با ورود سیستم‌های یادگیری ماشین، بخشی از رفتار دیگر مستقیماً در کد نوشته نمی‌شد؛ از داده یاد گرفته می‌شد. با مدل‌های زبانی بزرگ این پیچیدگی شکل تازه‌ای گرفت: علاوه بر کد، داده و مدل، حالا دستور مدل، زمینه، بازیابی دانش، حافظه، ابزارهای متصل، لایه‌های حفاظتی و ارزیابی هم بخشی از رفتار سیستم‌اند.

مدل فقط یکی از اجزای سیستم هوش مصنوعی است. داده، دستور مدل، بازیابی دانش، ارزیابی، حفاظت‌ها، مشاهده‌پذیری، مسیر جایگزین و بازبینی انسانی هم بخشی از سیستم‌اند.

پس پرسش‌های مهندسی عوض می‌شوند. چه چیزی نسخه‌بندی می‌شود؟ فقط کد یا دستور مدل و مجموعه‌داده‌ی ارزیابی هم؟ چه چیزی تست می‌شود؟ فقط API یا کیفیت خروجی مدل هم؟ چه چیزی قابل برگشت است؟ نسخه‌ی مدل، دستور مدل، شاخص بازیابی دانش یا سیاست محصول؟ چه کسی مالک رفتار خروجی است؟ اگر مدل مطمئن نیست، سیستم باید چه کند؟ اگر پاسخ خطرناک، نادرست یا خارج از سیاست محصول بود، چه لایه‌ای جلوی آن را می‌گیرد؟

یکی از سخت‌ترین بخش‌های SE4AI، تست و ارزیابی است. در سیستم‌های کلاسیک، اغلب می‌توانیم بگوییم برای این ورودی، خروجی دقیقاً باید این مقدار باشد. اما در سیستم‌های هوش مصنوعی، مخصوصاً مدل‌های زبانی، همیشه یک خروجی واحد و قطعی نداریم. چند پاسخ ممکن است قابل قبول باشند. یک پاسخ ممکن است از نظر جمله‌بندی عالی باشد، اما از نظر دامنه غلط باشد. ممکن است مدل در بیشتر نمونه‌ها خوب عمل کند، اما در چند سناریوی حساس خطای پرهزینه بدهد.

به همین دلیل، تست در سیستم‌های هوش مصنوعی فقط test case کلاسیک نیست. به ارزیابی نیاز داریم: نمونه‌های واقعی و نماینده، معیارهای کیفیت، ارزیابی انسانی در بخش‌های حساس، تست بازگشتی برای دستور مدل و نسخه‌ی مدل، سناریوهای خطرناک، و بررسی توهم مدل، سوگیری، حریم خصوصی و امنیت. در سیستم هوش مصنوعی، گاهی سؤال اصلی این نیست که «آیا خروجی دقیقاً برابر مقدار مورد انتظار است؟»؛ سؤال این است که «آیا خروجی برای این زمینه قابل قبول، امن، مفید و مطابق سیاست محصول است؟»

خروجی هوش مصنوعی نباید خام وارد محصول شود؛ باید اعتبارسنجی، ارزیابی، محدودسازی، پایش و در موقعیت‌های حساس، بازبینی انسانی داشته باشد.

این موضوع ما را به مسئولیت محصول می‌رساند. در نرم‌افزار کلاسیک، اگر تابعی خطا بدهد، معمولاً دنبال باگ در کد می‌گردیم. در سیستم هوش مصنوعی ممکن است کد درست اجرا شده باشد، API مدل پاسخ داده باشد، هیچ خطای اجرایی رخ نداده باشد، اما خروجی محصول غلط باشد. مثلاً چت‌بات پشتیبانی سیاست بازگشت وجه را اشتباه توضیح دهد. ابزار خلاصه‌سازی نکته‌ی مهم تیکت را حذف کند. سیستم رتبه‌بندی گروهی از کاربران را ناعادلانه پایین‌تر بیاورد. یا یک ابزار تولید محتوا ناخواسته داده‌ی حساس را وارد پاسخ کند.

از نگاه کاربر، این‌ها خطای «مدل» نیستند؛ خطای محصول‌اند. وقتی هوش مصنوعی وارد محصول می‌شود، خروجی مدل هم بخشی از تجربه‌ی کاربر و مسئولیت تیم است. نمی‌توانیم بگوییم «مدل این‌طور گفت» و کنار بکشیم. باید از قبل طراحی کنیم: کجا مدل اجازه‌ی پاسخ آزاد دارد؟ کجا باید فقط از منابع معتبر جواب بدهد؟ کجا باید بگوید نمی‌دانم؟ کجا خروجی فقط پیشنهاد است و اقدام خودکار نیست؟ کجا انسان باید وارد حلقه شود؟ و کجا ردپای حسابرسی لازم داریم؟

در سیستم‌های مبتنی بر مدل زبانی، چند جزء تازه وارد معماری می‌شوند. الگوی دستور مدل فقط یک متن ساده نیست؛ یک دارایی مهندسی است که باید نسخه داشته باشد، قابل بازبینی باشد و با تغییرش ارزیابی اجرا شود. بازیابی دانش فقط جست‌وجوی چند سند نیست؛ روی کیفیت پاسخ و ریسک توهم مدل اثر می‌گذارد. اتصال مدل به ابزارها فقط قابلیت جذاب محصولی نیست؛ باید محدودیت دسترسی، حسابرسی، خطایابی و مسیر جایگزین داشته باشد. حافظه‌ی مکالمه هم فقط امکانات محصولی نیست؛ می‌تواند مسئله‌ی حریم خصوصی، امنیت و کیفیت ایجاد کند.

حالا نقد اصلی بخش: بزرگ‌ترین خطای تیم‌ها این است که سیستم هوش مصنوعی را به مدل تقلیل می‌دهند. فکر می‌کنند اگر مدل قوی‌تر شود، مسئله حل است. اما در عمل، بسیاری از شکست‌ها از خود مدل شروع نمی‌شوند؛ از سیستم اطراف مدل می‌آیند: داده‌ی بد، تعریف مبهم مسئله، نداشتن ارزیابی، نبود مسیر جایگزین، سیاست محصولی نامشخص، داده‌ی حساس در دستور مدل، اعتماد بیش از حد به خروجی، نبود مشاهده‌پذیری، یا نبود مالکیت برای رفتار مدل.

مدل بهتر، سیستم بد را نجات نمی‌دهد؛ اگر داده، ارزیابی، حفاظت، پایش، سیاست محصول و مسیر جایگزین ضعیف باشند، خروجی فقط قانع‌کننده‌تر و خطرناک‌تر می‌شود.

مدل بهتر، معماری بد را نجات نمی‌دهد؛ فقط گاهی خرابی را قانع‌کننده‌تر پنهان می‌کند. اگر نمی‌دانیم خروجی هوش مصنوعی را چطور ارزیابی کنیم، هنوز آماده‌ی سپردن تصمیم مهم به آن نیستیم. اگر نمی‌دانیم در چه شرایطی باید بگوید «نمی‌دانم»، هنوز طراحی محصول کامل نشده است. اگر نمی‌دانیم وقتی مدل اشتباه کرد چه کسی پاسخ‌گوست، هنوز مالکیت روشن نداریم.

این نگاه یعنی SE4AI فقط بحث مدل و دقت نیست؛ بحث سیستم و مسئولیت است. باید بدانیم کدام داده وارد مدل می‌شود، کدام خروجی اجازه‌ی نمایش به کاربر دارد، کدام تصمیم نیاز به تأیید انسانی دارد، کدام رفتار باید ثبت و حسابرسی شود، و کدام تغییر باید با ارزیابی مقایسه شود. باید بتوانیم نسخه‌ی مدل، دستور مدل، بازیابی دانش و سیاست محصول را کنار هم ردیابی کنیم تا اگر رفتار محصول تغییر کرد، بفهمیم چرا.

برای ساخت سیستم هوش مصنوعی قابل اعتماد، باید چند چیز را از ابتدا جدی بگیریم. مسئله و معیار خوب بودن خروجی باید روشن باشد. داده‌ی ورودی و داده‌ی ارزیابی باید نماینده و قابل پیگیری باشند. دستور مدل و تنظیمات باید نسخه‌بندی شوند. خروجی باید پایش شود. برای خطا، عدم اطمینان، محتوای خطرناک یا درخواست خارج از محدوده باید مسیر جایگزین داشته باشیم. در کارهای حساس، انسان باید بخشی از طراحی باشد، نه وصله‌ای که بعد از حادثه اضافه می‌شود.

برای من، SE4AI یعنی پذیرفتن اینکه سیستم مبتنی بر هوش مصنوعی فقط یک مدل نیست. مدل مهم است، اما بدون داده‌ی خوب، دستور مدل قابل کنترل، ارزیابی، لایه‌ی حفاظتی، مشاهده‌پذیری، مسیر جایگزین، امنیت، تجربه‌ی کاربر و مسئولیت انسانی، محصول قابل اعتمادی ساخته نمی‌شود. هوش مصنوعی وقتی وارد محصول می‌شود، باید مثل بخشی از سیستم مهندسی شود؛ نه مثل جادویی که بیرون از قواعد مهندسی قرار دارد.

تا اینجا گفتیم سیستم هوش مصنوعی فقط مدل نیست و باید مهندسی شود. اما وقتی پای مدل، داده و تغییر مداوم رفتار وسط باشد، عملیات هم شکل تازه‌ای پیدا می‌کند. نمی‌توان مدل را یک‌بار مستقر کرد و فراموش کرد. داده تغییر می‌کند، توزیع ورودی عوض می‌شود، کیفیت افت می‌کند، و مدل باید پایش و گاهی بازآموزی شود. این ما را به بخش بعدی می‌رساند: MLOps.

وقتی مدل هم مثل کد، چرخه‌ی تولید و نگه‌داری می‌خواهد​

در بخش قبل گفتیم سیستم مبتنی بر هوش مصنوعی فقط یک مدل نیست. داده، دستور مدل، ارزیابی، حفاظت‌ها، مشاهده‌پذیری، مسیر جایگزین و مسئولیت انسانی هم بخشی از سیستم‌اند. حالا یک قدم عملیاتی‌تر برمی‌داریم: اگر مدل وارد محصول شد، چطور آن را در تولید زنده، قابل پایش، قابل بازگشت و قابل بهبود نگه داریم؟

یک صحنه‌ی آشنا را تصور کنیم. تیم داده یا تیم محصول یک مدل خوب ساخته است. در نوت‌بوک آزمایشی همه‌چیز امیدوارکننده است. داده‌ی آموزشی آماده شده، چند نمودار خوب داریم، معیارها مناسب‌اند و مدل روی داده‌ی تست عملکرد قابل قبولی نشان می‌دهد. همه خوشحال‌اند و جمله‌ی معروف شنیده می‌شود: «خب، حالا فقط مستقر کنیم.»

اما درست از همین‌جا درد واقعی شروع می‌شود. مدل در محیط تولید با داده‌هایی روبه‌رو می‌شود که همیشه شبیه داده‌ی آزمایشگاهی نیستند. رفتار کاربران تغییر می‌کند. فصل، کمپین، قیمت، سیاست محصول، بازار یا حتی شکل استفاده‌ی کاربران عوض می‌شود. ویژگی‌هایی که موقع آموزش تمیز و کامل بودند، در تولید دیر، ناقص یا با تعریف متفاوت می‌رسند. مدلی که امروز خوب کار می‌کند، ممکن است دو ماه بعد آرام‌آرام افت کند؛ بدون اینکه سرویس از کار بیفتد یا خطای واضحی بدهد.

اینجاست که MLOps وارد داستان می‌شود.

مرز MLOps با بخش قبل مهم است. SE4AI می‌پرسید سیستم مبتنی بر هوش مصنوعی را چطور درست طراحی کنیم: کیفیت خروجی، ارزیابی، حفاظت، تجربه‌ی کاربر، مسئولیت و معماری محصول. MLOps بیشتر روی چرخه‌ی عملیاتی مدل و داده تمرکز دارد: داده چطور آماده می‌شود، مدل چطور آموزش می‌بیند، نسخه‌ی مدل و داده چطور ثبت می‌شود، مدل چطور مستقر می‌شود، کیفیتش در تولید چطور پایش می‌شود، و اگر افت کرد یا داده تغییر کرد، چه می‌کنیم.

MLOps از نظر ذهنی به DevOps نزدیک است. در DevOps یاد گرفتیم کد فقط نوشته نمی‌شود؛ باید ساخته، تست، مستقر، پایش و در صورت نیاز برگردانده شود. اما در سیستم‌های یادگیری ماشین، فقط کد نداریم. داده و مدل هم دارایی‌های اصلی‌اند. در نرم‌افزار کلاسیک، اگر کد تغییر نکند، انتظار داریم رفتار سیستم نسبتاً پایدار بماند. اما در یادگیری ماشین، حتی اگر کد و مدل تغییر نکنند، دنیای بیرون تغییر می‌کند و کیفیت مدل می‌تواند افت کند.

در MLOps، دارایی مهندسی فقط کد نیست؛ داده، ویژگی، مدل، معیار ارزیابی و خط لوله‌ی آموزش هم دارایی مهندسی‌اند.

مدل فقط آموزش داده نمی‌شود؛ وارد چرخه‌ای از داده، آماده‌سازی، آموزش، ارزیابی، ثبت، استقرار، پایش و بازخورد می‌شود.

در مرحله‌ی آزمایش، نوت‌بوک ابزار بسیار خوبی است. می‌توانیم سریع ایده‌ها را امتحان کنیم، نمودار بکشیم، مدل‌ها را مقایسه کنیم و بفهمیم اصلاً مسئله ارزش ادامه دادن دارد یا نه. اما نوت‌بوک به‌تنهایی محصول نیست. اگر نمی‌دانیم داده دقیقاً از کجا آمده، چطور پاک‌سازی شده، چه ویژگی‌هایی ساخته شده، کدام نسخه از کد استفاده شده، چه پارامترهایی تنظیم شده و مدل با چه معیارهایی ارزیابی شده، بازتولید همان نتیجه بعداً سخت می‌شود.

مدلی که فقط در نوت‌بوک خوب کار می‌کند، هنوز محصول نیست؛ فقط یک شواهد آزمایشگاهی است. برای اینکه مدل وارد سیستم واقعی شود، باید آموزش آن تکرارپذیر باشد، داده‌اش قابل اعتبارسنجی باشد، مدلش نسخه داشته باشد، استقرارش کنترل‌شده باشد و کیفیتش بعد از استقرار دیده شود.

در یادگیری ماشین، داده فقط ورودی نیست؛ بخشی از رفتار سیستم است. اگر داده‌ی آموزشی نماینده‌ی دنیای واقعی نباشد، مدل در تولید بد عمل می‌کند. اگر schema داده تغییر کند، مدل ممکن است بی‌سروصدا خراب شود. اگر تعریف یک ویژگی عوض شود، مدل همان ورودی ظاهری را می‌گیرد، اما معنای آن عوض شده است. اگر داده دیر برسد یا ناقص باشد، خروجی مدل قابل اعتماد نیست.

مثلاً مدلی برای تشخیص تقلب داریم. اگر روش‌های تقلب تغییر کنند، رفتار کاربران در یک فصل خاص عوض شود، یا یک ویژگی مهم با تأخیر برسد، داده‌ی تولید با داده‌ی زمان آموزش فاصله می‌گیرد. مدل همچنان خروجی می‌دهد، اما کیفیتش ممکن است پایین آمده باشد. این نوع خرابی با خطای اجرایی معلوم نمی‌شود؛ باید با پایش داده و کیفیت مدل دیده شود.

در یادگیری ماشین، خرابی همیشه از کار افتادن سرویس نیست؛ گاهی افت آرام کیفیت مدل است، چون داده‌ی واقعی از داده‌ی زمان آموزش فاصله گرفته است.

اینجا مفهوم رانش مهم می‌شود. رانش داده یعنی توزیع داده‌ی ورودی در تولید با داده‌ی زمان آموزش فرق کند. رانش مدل یا افت کیفیت یعنی خروجی و عملکرد مدل در دنیای واقعی دیگر مثل گذشته قابل اعتماد نباشد. گاهی این افت روی کل کاربران دیده نمی‌شود، بلکه روی یک گروه یا بخش خاص پنهان می‌ماند. برای همین فقط دیدن یک عدد کلی مثل دقت کافی نیست. باید بدانیم مدل روی گروه‌ها، سناریوها و بخش‌های مهم محصول چطور رفتار می‌کند.

MLOps باید به اعتبارسنجی داده، کیفیت داده، سازگاری ویژگی‌ها و پایش توجه کند. باید بفهمیم آیا داده‌ای که مدل می‌بیند همان معنایی را دارد که زمان آموزش داشته است یا نه. باید تشخیص دهیم آیا توزیع پیش‌بینی‌ها تغییر کرده، تأخیر بالا رفته، خطای ویژگی‌ها زیاد شده، یا کیفیت مدل روی گروه خاصی افت کرده است.

بخش مهم دیگر، نسخه‌بندی و ثبت مدل است. وقتی مدل جدیدی مستقر می‌شود، باید بتوانیم بگوییم با چه داده‌ای آموزش دیده، چه کدی آن را ساخته، چه پارامترهایی داشته، چه معیارهایی گرفته، چه کسی آن را تأیید کرده و روی چه بخش‌هایی خوب یا بد عمل کرده است. اگر مدل جدید بدتر شد، نسخه‌ی قبلی باید قابل پیدا کردن و برگشت باشد.

اینجاست که مفاهیمی مثل رهگیری آزمایش‌ها، مخزن ثبت مدل و مدیریت خروجی‌های مدل مهم می‌شوند. ابزارهایی مثل MLflow، Weights & Biases، Kubeflow یا مخزن ویژگی‌هایی مثل Feast هرکدام بخشی از این مسئله را حل می‌کنند. اما ابزار به‌تنهایی کافی نیست. اگر تیم نداند معیار تصمیم‌گیری چیست، چه چیزی باید ثبت شود و چه زمانی یک مدل اجازه‌ی ورود به تولید دارد، مخزن ثبت مدل فقط تبدیل می‌شود به انبار فایل‌های مدل.

در نرم‌افزار معمولی، CI/CD معمولاً یعنی کد را بساز، تست کن و بعد مستقر کن. در یادگیری ماشین این چرخه پیچیده‌تر است. باید کد آموزش تست شود، داده اعتبارسنجی شود، مدل آموزش ببیند، مدل ارزیابی شود، اگر از حد قابل قبول بهتر بود ثبت شود، بعد به شکل کنترل‌شده مستقر شود و پس از آن رفتار مدل در تولید پایش شود. گاهی حتی از بازآموزی پیوسته حرف می‌زنیم؛ یعنی بازآموزی مداوم یا دوره‌ای مدل. اما اینجا هم باید مراقب باشیم: خودکار کردن بازآموزی بدون کنترل کیفیت داده، یعنی سرعت دادن به تولید مدل‌های بد.

نقد اصلی بخش این است: خیلی از تیم‌ها MLOps را با ابزار اشتباه می‌گیرند. فکر می‌کنند اگر MLflow، Kubeflow، خط لوله‌ی جذاب یا داشبورد داشته باشند، MLOps حل شده است. اما MLOps قبل از ابزار، یک نظم مهندسی است: تعریف مالکیت، معیار کیفیت، داده‌ی قابل اعتماد، بازتولیدپذیری، ارزیابی، پایش، برگشت و فرایند تصمیم‌گیری.

MLOps بدون تعریف روشن از کیفیت مدل، فقط اتوماسیون تولید خروجی است. اگر نمی‌دانیم مدل در تولید خوب کار می‌کند یا نه، داشتن خط لوله فقط ما را سریع‌تر به ابهام می‌رساند. مدل خوب در آزمایش الزاماً مدل خوب در محصول نیست. دقت کلی ممکن است افت کیفیت روی بخش‌های مهم را پنهان کند. تشخیص رانش بدون برنامه‌ی اقدام، فقط یک هشدار تزئینی است. پایش هم فقط تأخیر و در دسترس بودن سرویس نیست؛ کیفیت پیش‌بینی هم بخشی از سلامت سیستم است.

استقرار مدل پایان کار نیست؛ شروع نگه‌داری است. اگر مدل را مستقر کنیم و فراموش کنیم، تغییر داده و افت کیفیت دیر یا زود خودش را نشان می‌دهد.

ضدالگوی رایج این است که مدل را مستقر کنیم و بعد فراموشش کنیم. در روز استقرار همه‌چیز خوب به نظر می‌رسد. اما هفته‌ها و ماه‌ها بعد، داده تغییر می‌کند، کیفیت مدل افت می‌کند، کاربران رفتار متفاوتی نشان می‌دهند، هشدار مشخصی وجود ندارد و کسی دقیق نمی‌داند مدل فعلی با کدام داده و کدام کد ساخته شده است. اینجا مشکل فقط فنی نیست؛ اعتماد محصولی و تصمیم‌گیری سازمانی هم آسیب می‌بیند.

MLOps برای آزمایش ساده‌ی دانشگاهی یا یک نمونه‌ی اولیه‌ی کوچک شاید لازم نباشد. اگر هدف فقط یادگیری، ارائه‌ی اولیه یا اثبات امکان‌پذیری است، یک نوت‌بوک و چند معیار ساده می‌تواند کافی باشد. اما وقتی خروجی مدل روی کاربران واقعی، پول، ریسک، رتبه‌بندی، پیشنهاد، تشخیص تقلب، پشتیبانی یا تصمیم محصولی اثر می‌گذارد، دیگر با یک آزمایش طرف نیستیم. مدل بخشی از سیستم تولیدی است و باید مثل بخشی از سیستم تولیدی با آن رفتار کنیم.

برای من، MLOps یعنی مدل را از یک خروجی آزمایشگاهی به بخشی قابل اعتماد از سیستم تولید تبدیل کنیم. این کار فقط با مستقر کردن مدل تمام نمی‌شود؛ به داده‌ی قابل اعتماد، آموزش تکرارپذیر، نسخه‌بندی، ارزیابی، استقرار کنترل‌شده، پایش کیفیت، تشخیص رانش، برگشت و تصمیم‌گیری انسانی نیاز دارد. مدل در تولید زنده است، چون دنیای اطرافش تغییر می‌کند.

از یک برنامه‌ی ساده شروع کردیم و رسیدیم به سیستمی که داده، مدل، زیرساخت، عملیات، انسان، فرایند و هوش مصنوعی دارد. حالا دیگر مهندسی نرم‌افزار فقط نوشتن کد نیست؛ ساختن سیستمی است که در زمان، تغییر، خطا و رشد دوام بیاورد. بخش پایانی همین مسیر را جمع‌بندی می‌کند.

جمع‌بندی: وقتی نرم‌افزار بزرگ می‌شود، مسئله فقط کد نیست​

ما این مسیر را از یک جای ساده شروع کردیم: یک برنامه، چند endpoint، چند کاربر و چند نیاز روشن. در آن نقطه، خیلی از مفاهیمی که در این نوشته دیدیم شاید زیادی بزرگ، رسمی یا حتی نمایشی به نظر برسند. کسی که هنوز یک محصول کوچک دارد، شاید واقعاً نیازی به Kubernetes، GitOps، CQRS، Event Sourcing، BPMS، Chaos Engineering یا MLOps نداشته باشد. این نکته را باید جدی گرفت؛ معماری خوب یعنی انتخاب به‌اندازه، نه جمع کردن اسم‌های جذاب.

اما نرم‌افزار اگر زنده بماند، تغییر می‌کند. کاربرها بیشتر می‌شوند، تیم بزرگ‌تر می‌شود، نیازها از هم فاصله می‌گیرند، چند مصرف‌کننده‌ی مختلف پیدا می‌کنیم، سرویس‌ها به هم وابسته می‌شوند، داده زیاد می‌شود، خطاها پرهزینه‌تر می‌شوند، زیرساخت پیچیده‌تر می‌شود و کم‌کم پرسش‌های تازه‌ای پیش می‌آید: قرارداد API کجاست؟ هر مصرف‌کننده چه نیازی دارد؟ مرز دامنه کجاست؟ پیام‌ها چطور جابه‌جا می‌شوند؟ داده‌ی قدیمی را چطور مهاجرت می‌دهیم؟ اگر بخشی از سیستم خراب شد چه می‌شود؟ فرایندهای سازمانی کجا قابل پیگیری‌اند؟ و وقتی هوش مصنوعی وارد محصول شد، کیفیت و مسئولیت خروجی را چطور می‌سنجیم؟

این نوشته قرار نبود از همه‌ی این مفاهیم قهرمان بسازد. اتفاقاً در بیشتر بخش‌ها یک هشدار تکرار شد: هر ابزار و الگو اگر بی‌جا وارد شود، می‌تواند مسئله‌ی تازه بسازد. BFF اگر فقط کپی‌کاری منطق شود، بدهی می‌سازد. Event Sourcing اگر برای مسئله‌ی نامناسب انتخاب شود، خواندن و نگه‌داری را سخت می‌کند. Serverless اگر بدون فهم مدل اجرا و هزینه وارد شود، غافلگیر می‌کند. Low-code و BPMS اگر بدون مالکیت و مرز روشن رشد کنند، منطق را از جلوی چشم تیم پنهان می‌کنند. هوش مصنوعی اگر بدون زمینه، ارزیابی و مسئولیت انسانی استفاده شود، فقط خروجی قانع‌کننده‌تر تولید می‌کند؛ نه لزوماً نرم‌افزار بهتر.

از طرف دیگر، سادگی هم همیشه فضیلت نیست. سادگی وقتی ارزشمند است که مسئولانه باشد. اینکه همه‌چیز را در یک سرویس، یک جدول، یک جریان کاری، یک اسکریپت یا یک نوت‌بوک نگه داریم، شاید در شروع سریع باشد؛ اما اگر سیستم رشد کرده و هنوز هیچ مرزی، هیچ پایشی، هیچ تستی، هیچ قرارداد روشنی و هیچ مالکیتی نداریم، دیگر اسمش سادگی نیست. آنجا با سادگی بی‌مسئولیت طرفیم؛ چیزی که امروز راحت است و فردا هزینه‌اش را با کندی، خطا و ترس از تغییر پس می‌دهد.

پس خط میانی این است: نه معماری نمایشی، نه سادگی بی‌مسئولیت.

معماری نمایشی یعنی ابزارها را زودتر از درد واقعی وارد کنیم. سادگی بی‌مسئولیت یعنی درد واقعی را ببینیم و همچنان وانمود کنیم با چند فایل و چند دستور دستی همه‌چیز قابل کنترل است. مهندسی نرم‌افزار بالغ، بین این دو افراط حرکت می‌کند: مسئله را می‌فهمد، هزینه‌ی راه‌حل را می‌سنجد، و ابزار را وقتی وارد می‌کند که واقعاً به روشن‌تر شدن، قابل نگه‌داری‌تر شدن یا قابل اعتمادتر شدن سیستم کمک کند.

در این مسیر، تقریباً همه‌ی مفاهیم یک پیام مشترک داشتند: سیستم‌های نرم‌افزاری فقط از کد تشکیل نشده‌اند. قراردادها، داده‌ها، رخدادها، صف‌ها، زیرساخت، استقرار، مشاهده‌پذیری، مهاجرت داده، فرایندهای انسانی، ابزارهای داخلی، مدل‌های هوش مصنوعی و حتی تصمیم‌های سازمانی، همه بخشی از واقعیت نرم‌افزارند. اگر فقط کد را ببینیم، دیر یا زود آن بخش‌های پنهان از جایی دیگر خودشان را نشان می‌دهند.

همین‌جا ارزش نگاه مرحله‌ای روشن می‌شود. لازم نیست روز اول همه‌چیز را کامل و سنگین طراحی کنیم. بهتر است از ساده‌ترین راه مسئولانه شروع کنیم، اما حواسمان به نشانه‌های رشد باشد. وقتی چند مصرف‌کننده نیازهای متفاوت دارند، شاید BFF معنا پیدا کند. وقتی ارتباط سرویس‌ها زیاد می‌شود، شاید صف پیام یا معماری رخدادمحور لازم شود. وقتی زیرساخت با کلیک و حافظه‌ی افراد جلو می‌رود، IaC و GitOps جدی‌تر می‌شوند. وقتی داده‌ی زنده تغییر می‌کند، مهاجرت مرحله‌ای لازم می‌شود. وقتی مدل وارد تولید می‌شود، MLOps دیگر تزئین نیست.

اگر بخواهم کل این نوشته را در یک تصویر ذهنی خلاصه کنم، نرم‌افزار شبیه موجودی است که در زمان رشد می‌کند. اوایل فقط باید راه برود. بعد باید با دیگران حرف بزند. بعد باید بار بیشتری حمل کند. بعد باید بیمار نشود، یا اگر شد، زود بفهمیم. بعد باید در محیط‌های مختلف زندگی کند. بعد باید با داده، فرایند، انسان و هوش مصنوعی کنار بیاید. ما هم به‌عنوان مهندس، فقط سازنده‌ی چند تابع نیستیم؛ نگه‌دارنده‌ی این موجود در مسیر رشد هستیم.

این یعنی مهندسی نرم‌افزار، در معنای جدی‌اش، هنر انتخاب‌های مسئولانه در زمان است. گاهی انتخاب مسئولانه این است که ابزار تازه‌ای وارد نکنیم. گاهی انتخاب مسئولانه این است که بالاخره بپذیریم راه دستی و ساده‌ی قبلی دیگر جواب نمی‌دهد. گاهی باید پیچیدگی را بپذیریم، چون مسئله واقعاً پیچیده شده است. گاهی باید جلوی پیچیدگی را بگیریم، چون فقط از هیجان ابزار آمده، نه از نیاز سیستم.

در پایان، اگر خواننده بعد از این نوشته فقط نام این بیست مفهوم را حفظ کند، اتفاق مهمی نیفتاده است. هدف بهتر این است که وقتی در یک جلسه، طراحی، بازبینی، مهاجرت داده، انتخاب ابزار یا بحث معماری با یکی از این واژه‌ها روبه‌رو می‌شود، بتواند یک قدم عقب‌تر بایستد و بپرسد:

این مفهوم دقیقاً قرار است کدام مشکل ما را حل کند؟
آیا مشکل ما واقعاً به این اندازه رسیده است؟
چه هزینه‌ای پنهان می‌کند؟
چه چیزی را قابل مشاهده‌تر، قابل تغییرتر یا قابل اعتمادتر می‌کند؟
و اگر اشتباه انتخابش کنیم، چه چیزی سخت‌تر می‌شود؟

اگر این پرسش‌ها همراه ما بمانند، این مسیر ارزشش را داشته است. چون مهندسی نرم‌افزار خوب با حفظ کردن اسم الگوها ساخته نمی‌شود؛ با دیدن مسئله، فهمیدن زمینه، سنجیدن هزینه‌ها و انتخاب‌های مرحله‌ای ساخته می‌شود.

این نوشته درباره‌ی این نیست که کسی اصل تک‌مسئولیتی را «بد اجرا کرده» و اگر کمی دقیق‌تر اجرا می‌کرد، همه‌چیز درست می‌شد. نقد من کمی ریشه‌ای‌تر است: خودِ قاب‌بندی این اصل گاهی ما را با سؤال اشتباهی وارد طراحی می‌کند.

به‌جای اینکه از خودمان بپرسیم «این مرزبندی در طول زمان چه هزینه‌ای دارد؟»، خیلی زود می‌پرسیم: «این کلاس چند مسئولیت دارد؟» همین تغییر کوچک در سؤال، ما را آرام‌آرام به سمت شکستن کد بر اساس مسئولیت‌های ظاهری می‌برد: Validator، Policy، Factory، Writer، Service.

گاهی نتیجه، کدی است که از دور مرتب‌تر و حرفه‌ای‌تر به نظر می‌رسد؛ اما تصمیم اصلی دامنه‌ای در آن مالک روشن ندارد. حرف اصلی این متن همین است: جداسازی باید هزینه‌ی آینده را کم کند؛ اگر فقط ظاهر امروز را تمیزتر کند، هنوز باید از خودش دفاع کند.

بعضی اصل‌ها آن‌قدر خوش‌بیان و دلنشین‌اند که مخالفت با آن‌ها شبیه مخالفت با عقل سلیم به نظر می‌رسد. اصل تک‌مسئولیتی هم از همین جنس است. جمله‌ی «هر چیز فقط یک دلیل برای تغییر داشته باشد» کوتاه است، مرتب است، و در نگاه اول انگار عصاره‌ی طراحی خوب را در خودش دارد.

اما گاهی همین جمله‌های خیلی تمیز، دقیقاً همان‌جایی خطرناک می‌شوند که دیگر کسی درباره‌ی هزینه‌ی واقعی‌شان سؤال نمی‌پرسد.

مسئله این نیست که جداسازی همیشه بد است. مسئله این است که ما قبل از دیدن الگوی واقعی تغییر در کدبیس، وارد بازی دیگری می‌شویم: بازیِ شمردن مسئولیت‌ها، شکستن کلاس‌ها، نام‌گذاری نقش‌های فنی، و ساختن انتزاع‌هایی که شاید هیچ‌وقت هزینه‌شان را پس ندهند.

سؤال رایج در این قاب‌بندی معمولاً این است:

این کد چند مسئولیت دارد؟

اما سؤال مهندسی‌تر این است:

این مرزبندی در طول زمان چه چیزی را ارزان‌تر و چه چیزی را گران‌تر می‌کند؟

این دو سؤال شبیه هم نیستند. اولی ما را وارد بحث‌های تمام‌نشدنی درباره‌ی تعریف «مسئولیت» می‌کند. دومی مجبورمان می‌کند هزینه‌ی تصمیم را در طول عمر کد بسنجیم: فهم، تغییر، تست، ریویو، دیباگ، ورود آدم‌های تازه به تیم، و مقیاس‌پذیری این قاعده در کل کدبیس.

سؤال غلط: «چند مسئولیت دارد؟»​

اصل تک‌مسئولیتی می‌گوید هر ماژول باید فقط یک دلیل برای تغییر داشته باشد. روی کاغذ، این حرف بدی نیست. اتفاقاً اگر آن را دقیق و بالغ بفهمیم، دارد درباره‌ی تغییر حرف می‌زند، نه درباره‌ی کوتاه‌بودن فایل یا زیادبودن فعل‌ها.

اما پروژه‌ی واقعی به این تمیزی رفتار نمی‌کند. دلیل تغییر معمولاً یک چیز ساده، ثابت و تک‌محوری نیست. یک تغییر از محصول می‌آید، یکی از مقررات، یکی از مدل داده، یکی از کارایی، یکی از تست، یکی از مشاهده‌پذیری، و یکی از مالکیت تیمی. گاهی هم چندتا از این‌ها با هم وارد می‌شوند و همه‌ی مرزهای قبلی را به چالش می‌کشند.

حالا در چنین محیطی، وقتی از خودمان می‌پرسیم «این کلاس چند مسئولیت دارد؟»، خیلی زود وارد یک بازی تفسیری می‌شویم:

• یک نفر می‌گوید validation یک مسئولیت است.
• یکی می‌گوید policy یک مسئولیت است.
• یکی می‌گوید ساخت object یک مسئولیت است.
• یکی می‌گوید persistence یک مسئولیت است.

و نکته‌ی دردناک این است که همه می‌توانند با ادبیات SRP از خودشان دفاع کنند.

یکی می‌گوید این شرط‌ها را ببریم در Validator، چون اعتبارسنجی مسئولیت جداست. یکی می‌گوید تصمیم دامنه باید در Policy باشد. یکی می‌گوید ساخت آبجکت باید برود در Factory. یکی هم می‌گوید سرویس باید لاغر بماند و فقط orchestration کند.

هیچ‌کدام از این جمله‌ها ذاتاً غلط نیستند. خیلی وقت‌ها حتی نجات‌دهنده‌اند. مشکل این است که SRP به‌تنهایی به ما نمی‌گوید کدام‌یک از این جداسازی‌ها در طول زمان هزینه‌ی تغییر را کم می‌کند. فقط یک قاب جذاب می‌دهد: «مسئولیت‌ها را جدا کن.»

وقتی اصل، معیار عملیاتی روشن نمی‌دهد، هر کس برداشت خودش از «مسئولیت» را تبدیل به معماری می‌کند. همین‌جاست که کد از نظر ظاهری تمیز می‌شود، اما رفتار واقعی سیستم آرام‌آرام بین چند نقش فنی پخش می‌شود.

یک قانون کوچک و یک تصمیم بی‌مالک​

فرض کن قانون محصولی کوچکی عوض شده است:

انتقال‌های زیر ۵۰ هزار تومان دیگر نیاز به بررسی اضافه ندارند.

از بیرون، تغییر ساده است. یک قانون کوچک عوض شده. نه قرارداد API عوض شده، نه مدل داده، نه جریان اصلی محصول.

اما وارد کد که می‌شوی، سؤال ساده‌ای که باید جواب روشن داشته باشد، پخش می‌شود:

این تصمیم دقیقاً کجا زندگی می‌کند؟

آیا این حد در validator است؟ در policy؟ در ساختن تراکنش؟ در تست سرویس؟ در چند جای هم‌زمان؟

اینجا نباید حواسمان پرت تعداد فایل‌ها شود. تعداد فایل به‌تنهایی استدلال قوی‌ای نیست. تغییر زیاد می‌تواند کاملاً طبیعی و حتی نشانه‌ی کار درست باشد. اگر schema عوض شده، migration لازم بوده، مستندات اصلاح شده، تست‌ها به‌روز شده‌اند، قرارداد API تغییر کرده، یا observability باید با رفتار جدید هماهنگ می‌شده، این‌ها fan-out ضروری‌اند.

مشکل جای دیگری است: تصمیم واحد دامنه‌ای مالک روشن ندارد.

یعنی مسئله واقعاً چند مرز مستقل ندارد؛ یک تصمیم واحد قبلاً به اسم مسئولیت‌های جداگانه تکه‌تکه شده است. حالا برای فهم و اصلاح آن باید چند کلاس، چند تست و چند mock را کنار هم بگذاری تا تازه بفهمی تصمیم اصلی کجا پنهان شده است.

این همان جایی است که تمیزی ظاهری شروع می‌کند به گرفتن مالیات از تیم.

در یک کدبیس کوچک، شاید فقط کمی آزاردهنده باشد. در یک تیم بزرگ‌تر، این هزینه چند برابر می‌شود. یک نفر قانون محصولی را تغییر می‌دهد، نفر دوم تست را می‌خواند، نفر سوم ریویو می‌کند، نفر چهارم شش ماه بعد باگ را دیباگ می‌کند. اگر هر کدام برای فهم یک تصمیم ساده باید همان مسیر پراکنده را دوباره کشف کنند، هزینه‌ی طراحی فقط یک بار پرداخت نشده؛ بارها و بارها از جیب تیم کم شده است.

درد اصلی: جداسازی مسئولیت‌محور، نه تغییرمحور​

مشکل من «جداسازی» نیست. مشکل من جداسازی‌ای است که از سؤال غلط شروع می‌شود.

وقتی به‌جای محور تغییر، از «مسئولیت ظاهری» شروع کنیم، خیلی زود کد را بر اساس نقش‌های فنی می‌بریم:

نظم فنی همیشه بد نیست. اتفاقاً در خیلی از تیم‌ها مزیت جدی است. وقتی تازه‌وارد می‌داند validation کجاست، policy کجاست و persistence کجاست، ورودش به کدبیس ساده‌تر می‌شود. ساختار قابل پیش‌بینی کمک می‌کند آدم‌ها سریع‌تر در کد راه بیفتند. مالکیت لایه‌ها هم می‌تواند روشن‌تر شود.

اما همین نظم از جایی به بعد می‌تواند ضد خودش شود.

اگر یک تصمیم واحد دامنه‌ای بین Validator و Policy و Factory پخش شود، ساختار قابل پیش‌بینی دیگر کمک نمی‌کند؛ فقط باعث می‌شود تصمیم در کشوهای مرتب گم شود. مشکل کشو داشتن نیست. کشو، فهرست و نمایه گاهی دقیقاً همان چیزی است که یک کتاب را قابل استفاده می‌کند. مشکل وقتی شروع می‌شود که برای خواندن یک پاراگراف مجبور شوی پنج کشو را هم‌زمان باز کنی.

چند حالت خوب و بد​

برای اینکه بحث منصفانه بماند، باید بپذیریم خیلی از چیزهایی که نقد می‌کنم، در جای درست خودشان ابزارهای مفیدی‌اند. مشکل ابزار نیست؛ معیار تصمیم است. مشکل وقتی شروع می‌شود که ابزار مفید را بدون سنجیدن هزینه‌ی بلندمدت، به قاعده‌ی عمومی تبدیل کنیم.

شاهد کدی: انتقال پول​

حالا برگردیم به همان قانون انتقال زیر ۵۰ هزار تومان.

نسخه‌ی مستقیم‌تر شاید چیزی شبیه این باشد:

func (s *TransferService) Transfer(ctx context.Context, cmd TransferCommand) error {
    if cmd.Amount <= 0 {
        return ErrInvalidAmount
    }

    account, err := s.accounts.Get(ctx, cmd.SourceAccountID)
    if err != nil {
        return err
    }

    if cmd.Amount >= 50_000 && account.NeedsExtraCheck() {
        return ErrExtraCheckRequired
    }

    if !account.CanWithdraw(cmd.Amount) {
        return ErrInsufficientBalance
    }

    transfer := NewTransfer(cmd)

    if err := s.ledger.Record(ctx, transfer); err != nil {
        return err
    }

    return s.accounts.ApplyTransfer(ctx, transfer)
}

این کد ایده‌آل نیست. ممکن است ledger واقعاً مرز مستقل حسابداری باشد. ممکن است accounts ماژول جدا داشته باشد. ممکن است تصمیم‌های انتقال واقعاً باید در policy باشند. من از تابع‌های چاق و کلاس‌های خداگونه دفاع نمی‌کنم.

اما این نسخه یک مزیت دارد: خواننده می‌تواند مسیر تصمیم را ببیند. قانون ۵۰ هزار تومان همان‌جا وسط جریان دیده می‌شود.

نسخه‌ی SRPزده ممکن است از دور تمیزتر باشد:

func (s *TransferService) Transfer(ctx context.Context, cmd TransferCommand) error {
    if err := s.validator.Validate(ctx, cmd); err != nil {
        return err
    }

    decision, err := s.policy.Decide(ctx, cmd)
    if err != nil {
        return err
    }

    tx := s.factory.Build(cmd, decision)

    if err := s.writer.Write(ctx, tx); err != nil {
        return err
    }

    return s.updater.Apply(ctx, tx)
}

این نسخه هم لزوماً بد نیست. TransferService می‌تواند orchestrator سالمی باشد؛ یعنی dependencyهای معنادار را کنار هم بیاورد و مسیر تصمیم را روشن کند. اما اگر فقط pass-through chain باشد، یعنی کار را از یک collaborator به بعدی پاس بدهد و تصمیم اصلی را پنهان کند، مشکل داریم.

نسخه‌ی بد ماجرا وقتی است که قانون اصلی در چند تکه پخش شده باشد:

func (v *TransferValidator) Validate(cmd TransferCommand) error {
    if cmd.Amount <= 0 {
        return ErrInvalidAmount
    }

    if cmd.Amount < SmallTransferLimit && cmd.RequiresExtraCheckFlag {
        return ErrInvalidSmallTransfer
    }

    return nil
}

func (p *TransferPolicy) Decide(account Account, cmd TransferCommand) Decision {
    if cmd.Amount >= SmallTransferLimit && account.NeedsExtraCheck() {
        return Decision{RequiresExtraCheck: true}
    }

    return Decision{RequiresExtraCheck: false}
}

func (f *TransactionFactory) Build(cmd TransferCommand, decision Decision) Transfer {
    return Transfer{
        Amount: cmd.Amount,
        Status: statusFromDecision(decision),
    }
}

حالا اگر قانون ۵۰ هزار تومان تغییر کند، باید بفهمیم این حد در validator چه اثری دارد، در policy چه تصمیمی می‌سازد، در factory چه وضعیتی تولید می‌کند، و کدام تست‌ها با mock کردن policy فقط بخشی از رفتار را فرض گرفته‌اند.

مشکل این نیست که policy داریم. مشکل این است که تصمیم اصلی در یک جای روشن زندگی نمی‌کند.

تست هم همین‌جا می‌تواند هزینه را زیاد کند. interaction test همیشه بد نیست. mock کردن policy می‌تواند تست سرویس را سریع‌تر و متمرکزتر کند؛ قرار نیست هر تست سرویس کل مسیر را end-to-end اجرا کند. مشکل وقتی شروع می‌شود که mock تنها شاهد ما از رفتار باشد، قرارداد واقعی policy جداگانه تست نشده باشد، یا تست سرویس به جای سنجیدن اثر قابل مشاهده‌ی انتقال، فقط ثابت کند که policy با چه ورودی‌ای صدا زده شده است.

مثال کوچک‌تر: تابعی که فقط برای آینده abstract شده​

این بیماری فقط در کلاس‌های بزرگ و الگوهای معماری نیست. گاهی در یک تابع کوچک هم خودش را نشان می‌دهد.

مثلاً:

def get_enabled_payment_methods() -> list[PaymentMethod]:
    return list(
        PaymentMethod.objects
        .filter(is_enabled=True)
        .order_by("display_order")
    )

در نگاه اول، بی‌آزار است. حتی ممکن است کسی بگوید: «خب خوب است دیگر؛ اگر فردا خواستیم cache اضافه کنیم، همین‌جا اضافه می‌کنیم. اگر فردا filter جدید خواستیم، همین تابع را تغییر می‌دهیم.»

اما سؤال مهندسی این است:

آیا امروز واقعاً چنین محوری برای تغییر داریم، یا فقط یک query ساده را پشت یک اسم پنهان کرده‌ایم؟

این تابع می‌تواند خوب باشد اگر واقعاً مفهوم دامنه‌ای مشترکی داریم: «روش‌های پرداخت فعال». اگر چند caller همین قرارداد را می‌خواهند. اگر ترتیب display_order بخشی از قرارداد محصول است. اگر cache واقعاً نیاز شده یا نزدیک است.

اما اگر فقط یک‌بار استفاده شده، اگر cache هنوز فقط یک احتمال ذهنی است، اگر callerهای آینده معلوم نیستند، و اگر این تابع فقط query ساده‌ای را پنهان می‌کند، شاید inline بودن صادقانه‌تر باشد:

payment_methods = list(
    PaymentMethod.objects
    .filter(is_enabled=True)
    .order_by("display_order")
)

کد تکراری واقعی، از abstraction خیالی قابل تحمل‌تر است. چون تکرار را می‌بینی، اما abstraction غلط خودش را شبیه طراحی خوب جا می‌زند.

از کجا بفهمیم وارد مسیر غلط شده‌ایم؟​

من دنبال عدد قطعی نیستم. تعداد فایل، تعداد کلاس، تعداد mock یا تعداد interface به‌تنهایی حکم نمی‌دهد. این‌ها فقط proxy هستند. اگر تبدیلشان کنیم به هدف، خودشان فساد می‌سازند.

هدف اصلی این است:

کاهش هزینه‌ی فهم و تغییر در طول زمان

برای نزدیک‌شدن به این هدف، چند سیگنال بهتر از «چند مسئولیت دارد؟» داریم:

این‌ها حقیقت مطلق نیستند، اما از سؤال «چند مسئولیت دارد؟» عملیاتی‌ترند. چون به جای بحث‌های تفسیری، ما را می‌برند سمت رفتار واقعی کد در طول زمان.

نه God Class، نه SRPزدگی​

ممکن است کسی بگوید: «پس همه‌چیز را بریزیم در یک کلاس؟»

نه. این هم همان‌قدر بد است.

کلاس خداگونه هم هزینه‌ی خودش را دارد: تغییر خطرناک می‌شود، تست سخت می‌شود، مسئولیت‌های واقعاً نامرتبط قاطی می‌شوند، و هر اصلاح کوچک ممکن است جای دیگری را خراب کند. من از تابع‌های هزارخطی، duplication بی‌حد، و کلاس‌هایی که همه‌چیز را قورت می‌دهند دفاع نمی‌کنم.

اما نقد من این است که SRP ما را زیادی زود به سمت شکستن می‌برد. قبل از اینکه هزینه‌ی تغییر را بسنجیم، شروع می‌کنیم به تعریف مسئولیت و جداکردن اجزا.

مرز سالم نه با شعار «همه‌چیز جدا»، نه با شعار «همه‌چیز کنار هم» پیدا می‌شود. مرز سالم از مشاهده‌ی تغییر واقعی، مالکیت تصمیم، فهم انسانی و مقیاس تیمی می‌آید.

جمله‌ی من این است:

همه‌چیز را کنار هم نگه ندار؛ اما قبل از جداکردن، ثابت کن این جداسازی هزینه‌ی آینده را کم می‌کند.

اصل‌هایی که هزینه‌شان را نشان نمی‌دهند​

مشکل من با SRP این است که هزینه‌ی خودش را نشان نمی‌دهد. جمله‌ی «هر چیز فقط یک دلیل برای تغییر داشته باشد» آن‌قدر تمیز است که آدم حس می‌کند اگر کد را شکست، حتماً کار درستی کرده است.

اما طراحی خوب با حس خوب فرق دارد.

طراحی خوب باید در طول زمان دوام بیاورد. باید وقتی تیم بزرگ‌تر شد، هنوز قابل فهم باشد. باید وقتی قانون محصولی عوض شد، محل تغییر قابل پیش‌بینی باشد. باید وقتی refactor می‌کنیم، تست‌ها از رفتار محافظت کنند، نه از سیم‌کشی داخلی. باید وقتی ریویو می‌کنیم، تصمیم اصلی دیده شود، نه فقط choreography کلاس‌ها.

پس دفعه‌ی بعد که خواستی چیزی را به اسم اصل تک‌مسئولیتی جدا کنی، فقط نپرس:

آیا این مسئولیت جداست؟

بپرس:

این جداسازی چه چیزی را در آینده ارزان‌تر می‌کند؟

اگر جواب روشنی نداری، شاید هنوز وقت شکستن نرسیده است.

فرض کنید صفحه‌ای داریم که وضعیت حساب کاربر را نمایش می‌دهد. این صفحه باید تصمیم بگیرد آیا حساب فعال است یا نه، متن مناسب را نشان دهد، رنگ وضعیت را انتخاب کند، مبلغ را قالب‌بندی کند، پیام هشدار بسازد، و اگر کاربر محدودیت برداشت دارد، دکمه‌ی برداشت را غیرفعال کند.

در آغاز، شاید طبیعی به نظر برسد که همه‌ی این تصمیم‌ها را همان‌جا در خود رابط کاربری بنویسیم. بالاخره خروجی قرار است در همین صفحه دیده شود:

function AccountSummary({account}: {account: Account}) {
  const isBlocked = account.status === 'blocked'
  const isLowBalance = account.balance < 100_000
  const canWithdraw = account.status === 'active' && account.balance > 0

  const statusText = isBlocked ? 'مسدود' : 'فعال'
  const statusColor = isBlocked ? 'red' : 'green'
  const balanceText = `${account.balance.toLocaleString('fa-IR')} تومان`
  const warningText = isLowBalance
    ? 'موجودی حساب کم است'
    : null

  return (
    <section>
      <h2>{account.ownerName}</h2>
      <span className={statusColor}>{statusText}</span>
      <p>{balanceText}</p>
      {warningText && <p>{warningText}</p>}
      <button disabled={!canWithdraw}>برداشت</button>
    </section>
  )
}

این کد در نگاه نخست کوچک است، اما چند تصمیم مهم را در جایی گذاشته که آزمون‌کردنش معمولاً سخت‌تر از آزمون یک تابع ساده است. برای اطمینان از درستی این منطق، باید کامپوننت را رندر کنیم، وضعیت‌های مختلف را بسازیم، متن‌ها و دکمه‌ها را از خروجی پیدا کنیم، و گاهی حتی با رفتار مرورگر یا کتابخانه‌ی رابط کاربری درگیر شویم.

مسئله این نیست که رابط کاربری بد است. مسئله این است که رابط کاربری جای خوبی برای پنهان‌کردن منطق تصمیم‌گیری نیست.

در فصل «Presenters and Humble Objects»، رابرت مارتین به همین مشکل اشاره می‌کند: بعضی بخش‌های سیستم ذاتاً سخت‌تر آزمون می‌شوند؛ پس بهتر است این بخش‌ها تا حد ممکن ساده و کم‌منطق بمانند، و تصمیم‌های اصلی به بخش‌هایی منتقل شوند که آزمون‌کردنشان آسان‌تر است.

مشکل UI پرمنطق چیست؟​

رابط کاربری، مخصوصاً در برنامه‌های واقعی، معمولاً به چیزهای زیادی وابسته است: چارچوب، مرورگر، رخدادها، وضعیت محلی، کتابخانه‌ی طراحی، اندازه‌ی صفحه، زبان، دسترسی‌پذیری، و گاهی داده‌هایی که از چند مسیر می‌آیند. همین وابستگی‌ها باعث می‌شوند آزمون رابط کاربری معمولاً سنگین‌تر و شکننده‌تر از آزمون یک تابع معمولی باشد.

حالا اگر منطق تصمیم‌گیری را هم در همین لایه پنهان کنیم، دو مشکل را با هم ترکیب کرده‌ایم: هم منطق مهم داریم، هم محیط آزمون سخت.

در مثال حساب کاربر، این تصمیم‌ها درون کامپوننت پنهان شده‌اند:

• وضعیت حساب چه متنی داشته باشد؟
• چه رنگی برای وضعیت مناسب است؟
• دکمه‌ی برداشت چه زمانی فعال باشد؟
• هشدار موجودی چه زمانی نمایش داده شود؟
• مبلغ چطور قالب‌بندی شود؟

این‌ها فقط جزئیات نمایشی نیستند. بعضی از آن‌ها تصمیم‌های محصولی یا کسب‌وکاری‌اند. اگر اشتباه شوند، کاربر پیام نادرست می‌بیند یا عملیاتی را می‌بیند که نباید انجام دهد.

Presenter چه کمکی می‌کند؟​

ایده‌ی ارائه‌دهنده (Presenter) این است که داده‌ی خام را بگیرد و آن را به شکلی آماده کند که رابط کاربری فقط آن را نمایش دهد. یعنی به‌جای اینکه کامپوننت خودش تصمیم بگیرد چه چیزی نشان دهد، یک بخش جدا این تصمیم‌ها را می‌گیرد و خروجی آماده‌ی نمایش می‌سازد.

تصویر زیر همین مرز را نشان می‌دهد: رابط کاربری در سمت نمایش می‌ماند و کارهای پرتصمیم، مثل قالب‌بندی داده، انتخاب وضعیت، آماده‌سازی متن‌ها و ساخت مدل نمایش، در Presenter انجام می‌شود. نتیجه این است که UI کم‌منطق‌تر و پایدارتر می‌ماند، و Presenter را می‌توان با آزمون‌های ساده‌تر بررسی کرد.

برای نمونه، می‌توانیم منطق مثال قبلی را به یک تابع یا کلاس ساده منتقل کنیم:

interface AccountSummaryViewModel {
  ownerName: string
  statusText: string
  statusTone: 'success' | 'danger'
  balanceText: string
  warningText: string | null
  canWithdraw: boolean
}

function presentAccountSummary(account: Account): AccountSummaryViewModel {
  const isBlocked = account.status === 'blocked'
  const isLowBalance = account.balance < 100_000

  return {
    ownerName: account.ownerName,
    statusText: isBlocked ? 'مسدود' : 'فعال',
    statusTone: isBlocked ? 'danger' : 'success',
    balanceText: `${account.balance.toLocaleString('fa-IR')} تومان`,
    warningText: isLowBalance ? 'موجودی حساب کم است' : null,
    canWithdraw: account.status === 'active' && account.balance > 0,
  }
}

حالا کامپوننت ساده‌تر می‌شود:

function AccountSummary({account}: {account: Account}) {
  const viewModel = presentAccountSummary(account)

  return (
    <section>
      <h2>{viewModel.ownerName}</h2>
      <span data-tone={viewModel.statusTone}>{viewModel.statusText}</span>
      <p>{viewModel.balanceText}</p>
      {viewModel.warningText && <p>{viewModel.warningText}</p>}
      <button disabled={!viewModel.canWithdraw}>برداشت</button>
    </section>
  )
}

در این نسخه، کامپوننت هنوز لازم است. اما فروتن‌تر شده است. یعنی کمتر تصمیم می‌گیرد و بیشتر نمایش می‌دهد. منطق اصلی به جایی رفته که می‌توانیم آن را بدون رندر کردن صفحه و بدون درگیرشدن با مرورگر آزمون کنیم.

آزمون ساده‌تر، طراحی بهتر را نشان می‌دهد​

وقتی منطق در Presenter قرار می‌گیرد، آزمون آن بسیار ساده‌تر می‌شود:

test('presents blocked account summary', () => {
  const viewModel = presentAccountSummary({
    ownerName: 'علی محمدی',
    status: 'blocked',
    balance: 50_000,
  })

  expect(viewModel).toEqual({
    ownerName: 'علی محمدی',
    statusText: 'مسدود',
    statusTone: 'danger',
    balanceText: '۵۰٬۰۰۰ تومان',
    warningText: 'موجودی حساب کم است',
    canWithdraw: false,
  })
})

این آزمون نه به رندر نیاز دارد، نه به مرورگر، نه به کتابخانه‌ی رابط کاربری. یک ورودی می‌دهیم و خروجی را بررسی می‌کنیم. اگر قانون نمایش وضعیت یا پیام هشدار تغییر کند، آزمون دقیقاً همان بخش را نشان می‌دهد.

این همان سود اصلی الگوی Humble Object است: بخش سخت‌آزمون را کم‌منطق می‌کنیم و منطق را به جایی می‌بریم که آزمونش ساده، سریع و دقیق باشد.

Presenter فقط برای رابط کاربری نیست​

معمولاً وقتی از Presenter حرف می‌زنیم، ذهنمان به صفحه و کامپوننت می‌رود. اما همین ایده در پاسخ‌های رابط برنامه‌نویسی کاربردی (API)، خروجی گزارش، پیام‌های صف، فایل‌های خروجی و حتی قالب ایمیل هم کاربرد دارد.

فرض کنید یک کنترلر وب چنین کاری می‌کند:

async function getAccountResponse(request: Request, response: Response) {
  const account = await accountService.getById(request.params.id)

  if (account.status === 'blocked') {
    response.status(403).json({
      title: 'حساب مسدود است',
      canWithdraw: false,
    })
    return
  }

  response.json({
    title: account.ownerName,
    balance: `${account.balance.toLocaleString('fa-IR')} تومان`,
    canWithdraw: account.balance > 0,
  })
}

در اینجا هم منطق تصمیم‌گیری داخل بخشی رفته که بهتر است فروتن بماند. کنترلر وب باید درخواست را بگیرد، پاسخ را برگرداند و خطاهای چارچوب را مدیریت کند؛ اما لازم نیست همه‌ی منطق ارائه‌ی پاسخ را خودش نگه دارد.

می‌توانیم خروجی پاسخ را جدا کنیم:

function presentAccountResponse(account: Account): AccountResponse {
  if (account.status === 'blocked') {
    return {
      statusCode: 403,
      body: {
        title: 'حساب مسدود است',
        canWithdraw: false,
      },
    }
  }

  return {
    statusCode: 200,
    body: {
      title: account.ownerName,
      balance: `${account.balance.toLocaleString('fa-IR')} تومان`,
      canWithdraw: account.balance > 0,
    },
  }
}

و کنترلر را ساده‌تر نگه داریم:

async function getAccountResponse(request: Request, response: Response) {
  const account = await accountService.getById(request.params.id)
  const result = presentAccountResponse(account)

  response.status(result.statusCode).json(result.body)
}

در این طراحی، کنترلر همان Humble Object است: کم‌منطق، وابسته به چارچوب، و مسئول کارهای اجرایی. Presenter بخش قابل‌آزمون‌تر است: داده را می‌گیرد، تصمیم می‌گیرد و خروجی آماده‌ی پاسخ می‌سازد.

مرز دقیق کجاست؟​

نباید از این الگو برداشت افراطی داشته باشیم. قرار نیست هیچ شرطی در رابط کاربری باقی نماند. مثلاً شرطی مثل «اگر warningText وجود داشت، آن را نمایش بده» معمولاً مسئله‌ای ندارد. این یک شرط نمایشی ساده است.

اما شرط‌هایی که معنای کسب‌وکاری یا محصولی دارند بهتر است از رابط کاربری بیرون بیایند. برای نمونه:

• آیا کاربر اجازه‌ی برداشت دارد؟
• آیا این وضعیت باید هشدار قرمز بسازد؟
• آیا پاسخ باید با کد ۴۰۳ برگردد یا ۲۰۰؟
• آیا این مبلغ باید پنهان شود؟
• آیا کاربر باید پیام محدودیت ببیند؟

این‌ها تصمیم‌های مهم‌تری هستند و آزمون‌کردنشان باید آسان باشد.

یک قاعده‌ی ساده این است: اگر برای اطمینان از یک تصمیم مجبورید کامپوننت را رندر کنید، ولی خود تصمیم ربطی به رندر ندارد، احتمالاً آن تصمیم جای بهتری بیرون از UI دارد.

Humble Object یعنی بی‌ارزش‌کردن UI نیست​

گاهی وقتی می‌گوییم رابط کاربری باید کم‌منطق باشد، ممکن است این سوءبرداشت پیش بیاید که UI بخش کم‌اهمیت سیستم است. این برداشت درست نیست. رابط کاربری بسیار مهم است، چون جایی است که کاربر با سیستم روبه‌رو می‌شود.

اما مهم‌بودن UI به این معنا نیست که باید همه‌ی تصمیم‌ها در آن باشد. اتفاقاً چون رابط کاربری مهم است و خطاهایش مستقیم دیده می‌شوند، بهتر است تا حد ممکن ساده، قابل‌فهم و کم‌ریسک بماند.

در الگوی Humble Object، بخش فروتن تحقیر نمی‌شود؛ بلکه از بار اضافه محافظت می‌شود. رابط کاربری کار خودش را خوب انجام می‌دهد: نمایش، دریافت رخداد، فراخوانی عملیات، و اتصال به محیط اجرا. تصمیم‌های پیچیده‌تر در جایی قرار می‌گیرند که با هزینه‌ی کمتر آزمون می‌شوند.

چه زمانی Presenter لازم نیست؟​

هر صفحه یا پاسخ ساده‌ای نیاز به Presenter جدا ندارد. اگر یک صفحه فقط چند فیلد را مستقیم نمایش می‌دهد و تصمیم خاصی در آن نیست، افزودن Presenter ممکن است فقط کد را شلوغ کند.

برای نمونه، چنین چیزی شاید نیازی به Presenter جدا نداشته باشد:

function UserName({user}: {user: User}) {
  return <span>{user.name}</span>
}

اما اگر همین بخش کم‌کم شروع کند به تصمیم‌گیری درباره‌ی وضعیت، مجوز، قالب‌بندی، پیام، رنگ، هشدار و رفتار دکمه‌ها، آن‌وقت بهتر است مرزها را دوباره بررسی کنیم.

پس معیار اصلی، وجود منطق تصمیم‌گیری و هزینه‌ی آزمون است، نه صرفاً تعداد خط‌های کد.

یک ساختار ساده برای جداکردن Presenter​

در یک پروژه‌ی واقعی، ممکن است ساختار پوشه‌ها چیزی شبیه این باشد:

account-summary/
  account-summary.tsx
  account-summary-presenter.ts
  account-summary-presenter.test.ts

یا اگر با پاسخ رابط برنامه‌نویسی کاربردی کار می‌کنید:

account/
  account-controller.ts
  account-response-presenter.ts
  account-response-presenter.test.ts

در این ساختار، فایل UI یا کنترلر کوچک و اجرایی می‌ماند، و منطق آماده‌سازی خروجی در فایل Presenter قرار می‌گیرد. آزمون هم کنار همان منطق نوشته می‌شود.

این ساختار قرار نیست قانون همیشگی باشد، اما کمک می‌کند مرز بین «نمایش» و «آماده‌سازی برای نمایش» روشن بماند.

پیشنهاد عملی​

برای استفاده از این ایده، لازم نیست همه‌ی صفحه‌ها و کنترلرها را بازنویسی کنید. از بخش‌هایی شروع کنید که منطق تصمیم‌گیری در آن‌ها پنهان شده و آزمون‌کردنشان سخت است.

چیزهایی که باید بررسی شوند:

• آیا صفحه یا کنترلر چند شرط محصولی یا کسب‌وکاری دارد؟
• آیا برای آزمون یک تصمیم ساده مجبورید UI را رندر کنید؟
• آیا قالب‌بندی متن، عدد، وضعیت و پیام‌ها در چند جای مختلف تکرار شده است؟
• آیا خطاهای نمایشی به‌خاطر تصمیم‌های پنهان در UI رخ می‌دهند؟
• آیا می‌توان خروجی موردنیاز صفحه را به‌صورت یک View Model روشن تعریف کرد؟

چیزهایی که نباید بی‌دلیل تغییر کنند:

• کامپوننت‌های ساده‌ای که فقط داده را نمایش می‌دهند.
• شرط‌های نمایشی کوچک، مثل وجود یا نبود یک متن آماده.
• ساختارهایی که هنوز درد واقعی در آزمون یا تغییر ایجاد نکرده‌اند.
• منطق‌هایی که جای درستشان واقعاً در خود تعامل کاربر است، نه در Presenter.

برای اعتبارسنجی تغییر، دست‌کم این گام‌ها را اجرا کنید:

npm test
npm run lint
npm run typecheck

اگر پروژه‌ی شما این فرمان‌ها را ندارد، معادل آن‌ها را اجرا کنید. بعد از جداسازی، بهتر است آزمون Presenter را جداگانه بنویسید و یک آزمون سبک هم برای خود UI نگه دارید تا مطمئن شوید داده‌ی آماده‌شده درست نمایش داده می‌شود.

جمع‌بندی​

الگوی Presenter و Humble Object می‌خواهد ما منطق مهم را از بخش‌هایی جدا کنیم که آزمون‌کردنشان سخت‌تر است. رابط کاربری، کنترلر وب، فریم‌ورک و ابزارهای بیرونی لازم‌اند، اما بهتر است کم‌منطق بمانند.

هرچه بخش سخت‌آزمون کم‌ادعاتر باشد، آزمون‌پذیری سیستم بیشتر می‌شود. تصمیم‌ها، قالب‌بندی‌ها و آماده‌سازی خروجی اگر در Presenter قرار بگیرند، ساده‌تر آزمون می‌شوند و تغییرشان ریسک کمتری دارد.

طراحی خوب همیشه به معنی ساختن لایه‌های زیاد نیست. گاهی یعنی یک تصمیم ساده: چیزی که سخت آزمون می‌شود، فروتن بماند؛ چیزی که مهم و پرمنطق است، به جایی برود که بتوان آن را روشن، سریع و مطمئن آزمود.

واکنش نخست معمولاً فنی و سریع است: یک واردسازی را جابه‌جا می‌کنی، آن را به درون تابع می‌بری، نام یک فایل را عوض می‌کنی، یا چند خط کد را کمی عقب و جلو می‌کنی. برنامه دوباره اجرا می‌شود و خطا از بین می‌رود.

اما پرسش اصلی همین‌جاست:

آیا مشکل حل شد، یا فقط صدای هشدار را خاموش کردیم؟

این نوشته درباره‌ی همین هشدارهای کوچک است؛ هشدارهایی که گاهی از مسئله‌ای عمیق‌تر خبر می‌دهند: وابستگی چرخه‌ای. یعنی جایی که چند بخش از نرم‌افزار به‌جای آنکه با مرزهای روشن با هم همکاری کنند، آن‌قدر به هم گره می‌خورند که هر کدام برای فهمیده‌شدن یا اجراشدن، به دیگری نیاز دارد.

پایتون نمونه‌ی خوبی برای دیدن این مسئله است، چون خطای واردسازی چرخه‌ای را زود و آشکار نشان می‌دهد. اما موضوع اصلی این نوشته پایتون نیست. موضوع اصلی، شکل وابستگی‌ها در طراحی نرم‌افزار است.

یک مثال ساده؛ جایی که گره آرام شکل می‌گیرد​

فرض کنیم سامانه‌ای داریم با دو بخش ساده:

• بخش کاربر، برای ساختن و مدیریت حساب‌ها؛
• بخش پیام‌رسانی، برای فرستادن پیام‌ها.

در آغاز، همه‌چیز طبیعی است. بخش کاربر پس از ساختن حساب، باید پیام خوشامدگویی بفرستد. پس به بخش پیام‌رسانی نیاز دارد.

بخش کاربر → بخش پیام‌رسانی

کمی بعد، بخش پیام‌رسانی برای ساختن متن پیام، به نام و وضعیت کاربر نیاز پیدا می‌کند. پس آن هم به بخش کاربر وابسته می‌شود.

بخش پیام‌رسانی → بخش کاربر

حالا اگر این دو خط را کنار هم بگذاریم، با چرخه روبه‌رو می‌شویم:

بخش کاربر → بخش پیام‌رسانی → بخش کاربر

هیچ‌کدام از این دو تصمیم، به‌تنهایی عجیب نیست. حتی هر دو قابل دفاع‌اند. اما حاصل آن‌ها طراحی‌ای است که در آن دو بخش دیگر به‌راحتی از هم جدا نمی‌شوند.

مشکل چرخه‌ها معمولاً همین است: با یک تصمیم بزرگ و آشکار وارد سیستم نمی‌شوند؛ با چند تصمیم کوچک و به‌ظاهر منطقی ساخته می‌شوند.

وابستگی چرخه‌ای یعنی چه؟​

برای ساده‌کردن بحث، نرم‌افزار را مثل یک نقشه ببینیم. هر ماژول، بسته یا مؤلفه یک نقطه است. هر وابستگی هم یک پیکان.

اگر «الف» برای کار کردن به «ب» نیاز داشته باشد، پیکان از «الف» به «ب» می‌رود:

الف → ب

تا اینجا مسئله‌ای نیست. مشکل از جایی آغاز می‌شود که مسیر پیکان‌ها دوباره به نقطه‌ی آغاز برگردد:

الف → ب → پ → الف

در این حالت، دیگر با چند جزء مستقل طرف نیستیم. با مجموعه‌ای طرفیم که اجزایش به هم قفل شده‌اند. «الف» بدون «ب» کامل فهمیده نمی‌شود، «ب» بدون «پ» ناقص است، و «پ» دوباره به «الف» برمی‌گردد.

این همان چیزی است که در معماری نرم‌افزار اهمیت دارد: جهت وابستگی‌ها.

معماری فقط انتخاب چارچوب، پایگاه داده یا ابزار استقرار نیست. بخش مهمی از معماری این است که بدانیم کدام بخش‌ها حق دارند به کدام بخش‌ها وابسته باشند، و کدام وابستگی‌ها باید ممنوع، محدود یا دست‌کم آشکار باشند.

چرا این چرخه‌ها دردسرساز می‌شوند؟​

وابستگی چرخه‌ای همیشه برنامه را همان لحظه خراب نمی‌کند. گاهی خطر آن آرام‌تر و پنهان‌تر است. کد کار می‌کند، اما کم‌کم سخت‌تر فهمیده می‌شود، سخت‌تر آزموده می‌شود و سخت‌تر تغییر می‌کند.

۱. فهم کد سنگین‌تر می‌شود​

در طراحی خوب، می‌توان یک بخش را باز کرد و تا حد زیادی همان‌جا فهمید که چه می‌کند. اما در طراحی چرخه‌ای، خواننده مدام میان فایل‌ها و مفاهیم رفت‌وبرگشت می‌کند.

برای فهمیدن بخش کاربر، باید پیام‌رسانی را دید. برای فهمیدن پیام‌رسانی، باید دوباره بخش کاربر را دید. نتیجه این است که یک تغییر کوچک، به بررسی چند بخش وابسته تبدیل می‌شود.

۲. تغییرها اثر موجی پیدا می‌کنند​

وقتی دو بخش به هم قفل شده‌اند، تغییر در یکی ممکن است دیگری را هم بشکند؛ حتی اگر از نظر مفهومی انتظار چنین اثری نداشته باشیم.

این همان جایی است که توسعه‌دهنده‌ها کم‌کم محتاط می‌شوند. نه چون کد حتماً بزرگ است، بلکه چون معلوم نیست تغییر یک بخش، کجای دیگر را تحت تأثیر قرار می‌دهد.

۳. آزمون‌پذیری کم می‌شود​

آزمودن یک بخش وقتی ساده است که بتوان آن را جدا ساخت و اجرا کرد. اما وقتی «الف» برای ساخته‌شدن به «ب» نیاز دارد و «ب» هم به «الف»، جداسازی سخت می‌شود.

در چنین وضعی، آزمون‌های کوچک و روشن جای خود را به آزمون‌های بزرگ‌تر، شکننده‌تر و پر از وصله می‌دهند.

۴. راه‌اندازی سیستم حساس می‌شود​

در برخی زبان‌ها و چارچوب‌ها، ترتیب ساخته‌شدن اجزا مهم است. چرخه‌ها این ترتیب را شکننده می‌کنند. در پایتون، این شکنندگی هنگام واردسازی دیده می‌شود. در سامانه‌های بزرگ‌تر، ممکن است هنگام راه‌اندازی سرویس‌ها، ساختن وابستگی‌ها یا بارگذاری تنظیمات خودش را نشان دهد.

نمونه‌ی ملموس در پایتون​

پایتون چرخه‌های وابستگی را زود لو می‌دهد، چون ماژول‌ها هنگام واردسازی اجرا می‌شوند. اگر دو فایل در سطح بالای خود به هم وابسته باشند، ممکن است یکی از آن‌ها به چیزی نیاز داشته باشد که هنوز ساخته نشده است.

این نمونه را ببینیم:

from notifications import send_welcome_message


class User:
    pass


def create_user():
    user = User()
    send_welcome_message(user)
    return user

from users import User


def send_welcome_message(user: User):
    print("Welcome!")

در نگاه اول، هر دو واردسازی طبیعی به نظر می‌رسند. فایل users.py برای فرستادن پیام به notifications.py نیاز دارد. فایل notifications.py هم برای اشاره به نوع کاربر، User را از users.py وارد کرده است.

اما همین رابطه‌ی دوطرفه می‌تواند مشکل بسازد. پایتون هنگام واردسازی، فایل‌ها را اجرا می‌کند. اگر یکی از فایل‌ها هنوز کامل آماده نشده باشد و فایل دیگر بخواهد از آن نامی را بردارد، خطا رخ می‌دهد.

راه‌حل سریع ممکن است این باشد که واردسازی دوم را به درون تابع ببریم یا برای اشاره‌های نوعی از روش‌هایی مثل TYPE_CHECKING استفاده کنیم. این روش‌ها گاهی درست و لازم‌اند. اما نباید پرسش اصلی را پنهان کنند:

آیا پیام‌رسانی واقعاً باید کلاس کامل کاربر را بشناسد؟

شاید کافی باشد فقط نام و رایانامه‌ی کاربر را بگیرد. شاید باید یک قرارداد کوچک‌تر تعریف شود. شاید هم مفهوم مشترکی وجود دارد که باید از هر دو ماژول بیرون کشیده شود.

آیا هر چرخه‌ای بد است؟​

نه. پاسخ دقیق‌تر این است: چرخه‌ها یکسان نیستند.

گاهی چرخه فقط برای بررسی نوع‌ها ساخته شده است و در زمان اجرای برنامه نقشی ندارد. در این حالت، می‌توان آن را با روش‌هایی مثل واردسازی مشروط از مسیر اجرا بیرون برد.

گاهی هم چرخه کوچک، محدود و آگاهانه است. شاید شکستن آن طراحی را پیچیده‌تر کند و سود چندانی نداشته باشد. در چنین وضعی، پذیرش چرخه می‌تواند تصمیمی عملی باشد؛ به شرطی که پنهان و بی‌مرز رها نشود.

اما چرخه زمانی نگران‌کننده می‌شود که در مسیر اصلی اجرای برنامه باشد، مرز لایه‌ها را بشکند، آزمون‌پذیری را کم کند، یا تغییر یک بخش را به تغییر بخش‌های نامرتبط گره بزند.

پس پرسش درست این نیست:

آیا هر چرخه‌ای بد است؟

پرسش دقیق‌تر این است:

این چرخه چه چیزهایی را به هم گره زده، چه زمانی فعال می‌شود، و چه هزینه‌ای به فهم، آزمون و تغییر سیستم تحمیل می‌کند؟

نگاه معماری نرم‌افزار​

در معماری نرم‌افزار، وابستگی‌ها موضوعی حاشیه‌ای نیستند. بسیاری از تصمیم‌های مهم معماری، در نهایت، درباره‌ی همین پرسش‌اند:

چه چیزی مجاز است به چه چیزی وابسته باشد؟

رابرت مارتین در بحث طراحی مؤلفه‌ها از اصلی به نام اصل وابستگی‌های بدون چرخه یاد می‌کند. مضمون این اصل ساده است: گراف وابستگی میان مؤلفه‌ها نباید چرخه داشته باشد.

این اصل را نباید مثل یک قانون خشک خواند. ارزش آن در این است که ما را وادار می‌کند جهت وابستگی‌ها را ببینیم. وقتی دو مؤلفه به هم نیاز دارند، شاید یکی از این پرسش‌ها بی‌پاسخ مانده است:

• آیا مسئولیت‌ها درست جدا شده‌اند؟
• آیا یک مفهوم مشترک باید به جای سومی منتقل شود؟
• آیا یکی از بخش‌ها باید به قرارداد وابسته باشد، نه به پیاده‌سازی مشخص؟
• آیا جهت وابستگی با جهت تغییرهای واقعی سیستم سازگار است؟

از این زاویه، خطای واردسازی در پایتون فقط یک نشانه‌ی محلی است. مسئله‌ی اصلی ممکن است این باشد که طراحی، مرزهای روشنی برای وابستگی‌ها نگذاشته است.

با چرخه‌ها چه کنیم؟​

برای برخورد با وابستگی چرخه‌ای، یک نسخه‌ی همیشگی وجود ندارد. اما چند راهکار معمولاً کمک می‌کنند.

۱. مفهوم مشترک را بیرون بکشیم​

اگر دو بخش به یک نوع، ثابت، تابع یا قرارداد مشترک نیاز دارند، شاید آن مفهوم واقعاً متعلق به هیچ‌کدام از آن دو نیست.

به‌جای این:

users.py → notifications.py → users.py

می‌توانیم به این برسیم:

users.py          → shared.py
notifications.py → shared.py

با این کار، دو بخش هنوز از یک مفهوم مشترک استفاده می‌کنند، اما دیگر به هم قفل نشده‌اند.

۲. به قرارداد وابسته شویم، نه به جزئیات​

گاهی یک ماژول فقط به بخش کوچکی از اطلاعات ماژول دیگر نیاز دارد، اما به کل آن وابسته شده است. برای نمونه، پیام‌رسانی شاید فقط نام و رایانامه‌ی کاربر را بخواهد، نه کل کلاس کاربر را.

هرچه وابستگی کوچک‌تر و دقیق‌تر باشد، تغییرهای آینده کم‌هزینه‌تر می‌شوند.

۳. جهت وابستگی را برگردانیم​

گاهی جهت وابستگی اشتباه است. برای نمونه، منطق دامنه نباید مستقیماً به ابزار پیام‌رسانی وابسته شود. شاید بهتر باشد دامنه فقط یک رویداد تولید کند: «کاربر ساخته شد». سپس بخش دیگری آن رویداد را بشنود و پیام بفرستد.

دامنه → رویداد
شنونده‌ی رویداد → پیام‌رسانی

در این طراحی، دامنه از جزئیات پیام‌رسانی بی‌خبر می‌ماند.

۴. واردسازی محلی را با احتیاط به کار ببریم​

در پایتون، بردن واردسازی به درون تابع گاهی راهکاری درست است. اما اگر این کار فقط برای پنهان‌کردن درهم‌تنیدگی دو ماژول باشد، مشکل طراحی همچنان باقی است.

واردسازی محلی می‌تواند درمان باشد؛ اما گاهی فقط مسکن است.

چرخه‌ها را باید دید، نه فقط حذف کرد​

هدف این نیست که هر چرخه‌ای را بی‌درنگ ممنوع کنیم. هدف این است که چرخه‌ها پنهان نمانند.

در پروژه‌های کوچک، شاید بتوان با خواندن چند فایل چرخه را دید. اما در پروژه‌های بزرگ، بهتر است از ابزارهای تحلیل ایستا کمک گرفت. این ابزارها می‌توانند گراف وابستگی ماژول‌ها را بسازند و چرخه‌ها را گزارش کنند.

حتی می‌توان در فرایند یکپارچه‌سازی پیوسته، قاعده‌ای گذاشت که چرخه‌های تازه را آشکار کند. این کار شبیه آزمون‌نوشتن برای معماری است: فقط رفتار برنامه را نمی‌سنجیم، شکل وابستگی‌های آن را هم زیر نظر می‌گیریم.

جمع‌بندی​

وابستگی چرخه‌ای را نه باید بیش از اندازه بزرگ کرد، نه باید ساده از کنار آن گذشت.

گاهی با یک اصلاح کوچک، مشکل اجرایی حل می‌شود. اما اگر همان چرخه نشان دهد که دو بخش بیش از اندازه به هم گره خورده‌اند، حل واقعی در طراحی است، نه در جابه‌جایی چند خط کد.

پرسش پایانی این است:

آیا این چرخه حاصل یک نیاز آگاهانه و کنترل‌شده است، یا نشانه‌ای از مرزبندی مبهم میان مسئولیت‌ها؟

اگر پاسخ روشن باشد، شاید چرخه‌ای کوچک پذیرفتنی باشد. اما اگر پاسخ مبهم بماند، همان چرخه‌ی کوچک می‌تواند سرنخی باشد از گره‌ای پنهان در طراحی نرم‌افزار.

منابع پیشنهادی برای مطالعه‌ی بیشتر​

• Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017.
• Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices, 2002.
• Mark Richards and Neal Ford, Fundamentals of Software Architecture: An Engineering Approach, 2020.
• Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures: Support Constant Change, 2017.
• Python Documentation, The import system.
• Python Documentation, Programming FAQ: Circular imports.
• mypy Documentation, Annotation issues at runtime.

ادسخر دایجسترا نوشت: برنامه‌نویس.

کارمندان آمستردام نپذیرفتند. از نگاه آنان، چنین شغلی وجود نداشت. نه اینکه دایجسترا کاری نمی‌کرد؛ مسئله این بود که جهان هنوز برای کاری که او انجام می‌داد، نام و جایگاه روشنی نداشت.

در سند رسمی ازدواجش، به جای «برنامه‌نویس» نوشتند: فیزیک‌دان نظری.

همین صحنه برای آغاز قصه کافی است: مردی که بعدها یکی از چهره‌های بزرگ علوم رایانه شد، در روز ازدواجش حتی نتوانست شغل واقعی خود را روی کاغذ رسمی ثبت کند.

پیش از آنکه برنامه‌نویسی نامی داشته باشد​

دهه‌ی ۱۹۵۰ را تصور کنیم.

رایانه هنوز وارد زندگی روزمره نشده بود. نه رایانه‌ی شخصی در کار بود، نه تلفن هوشمند، نه نقشه‌ای که مسیر را در چند ثانیه نشان دهد. رایانه‌ها دستگاه‌هایی بزرگ، کمیاب و گران بودند؛ بیشتر در آزمایشگاه‌ها و مراکز پژوهشی دیده می‌شدند، نه در خانه و خیابان و محل کار مردم.

در چنین زمانی، «برنامه‌نویسی» هنوز آن معنایی را نداشت که امروز دارد. امروز وقتی کسی می‌گوید برنامه‌نویس است، اصل شغلش برای دیگران روشن است. شاید بپرسند در چه حوزه‌ای کار می‌کند، چه سامانه‌هایی می‌سازد، یا با چه زبان‌هایی می‌نویسد؛ اما کمتر کسی می‌پرسد: «اصلاً چنین شغلی وجود دارد؟»

برای دایجسترا، ماجرا این‌قدر ساده نبود.

او در جوانی میان دو راه ایستاده بود. یک راه، فیزیک نظری بود؛ رشته‌ای شناخته‌شده، جدی و محترم. راه دیگر، کار با رایانه و برنامه‌نویسی بود؛ مسیری تازه، مبهم و هنوز بی‌اعتبار در چشم بسیاری از مردم.

دایجسترا باید تصمیم می‌گرفت: آیا باید در راهی قدم بگذارد که آینده‌اش روشن نیست، یا به مسیر آشناتر فیزیک برگردد؟

گفت‌وگویی که مسیر را عوض کرد​

دایجسترا بعدها در سخنرانی جایزه‌ی تورینگ خود، که با نام برنامه‌نویس فروتن شناخته می‌شود، از این تردید گفت. او پس از چند سال برنامه‌نویسی هنوز مطمئن نبود این کار واقعاً حرفه‌ای محترم است یا نه.

برای پیدا کردن پاسخ، نزد آدریان فان وینگاردن رفت؛ کسی که در مرکز ریاضی آمستردام نقش مهمی در مسیر فکری او داشت.

پرسش دایجسترا ساده بود، اما پشت آن یک نگرانی بزرگ پنهان شده بود:

آیا برنامه‌نویسی چیزی هست که بتوان یک عمر را صرف آن کرد؟

پاسخ فان وینگاردن سرنوشت‌ساز بود. او به دایجسترا نگفت مسیر آماده است. نگفت همه‌چیز روشن و پذیرفته‌شده است. برعکس، گفت رایانه‌ها آمده‌اند که بمانند، و چون برنامه‌نویسی هنوز رشته‌ای بالغ نشده، کسانی باید باشند که به ساختن آن کمک کنند.

این پاسخ، وعده‌ی آسایش نبود؛ دعوت به ساختن بود.

دایجسترا وارد حرفه‌ای نشد که نام، رسمیت و معیارهایش از پیش آماده باشد. او وارد جهانی شد که هنوز باید برای خود زبان، روش و شأن فکری می‌ساخت.

یک واژه که زمانه هنوز آن را نمی‌فهمید​

حالا دوباره به آن فرم ازدواج برگردیم.

دایجسترا نوشت: برنامه‌نویس.
کارمندان نپذیرفتند.
در سند نوشتند: فیزیک‌دان نظری.

این صحنه، در ظاهر اداری و ساده است؛ اما معنای عمیقی دارد. گاهی یک واژه زودتر از زمانه‌ی خود پدیدار می‌شود. هست، اما هنوز در فرم‌ها جا ندارد. واقعی است، اما هنوز رسمیت پیدا نکرده است.

«برنامه‌نویس» برای دایجسترا واقعی بود.
برای اداره‌ی ثبت، نه.

شاید آن کارمند هرگز تصور نمی‌کرد چند دهه بعد، جهان پر از آدم‌هایی شود که خود را برنامه‌نویس، مهندس نرم‌افزار، پژوهشگر الگوریتم، معمار نرم‌افزار یا متخصص سامانه‌های رایانشی می‌نامند.

برای او، برنامه‌نویسی هنوز شغل نبود.
برای دایجسترا، آینده بود.

یک کافه، یک فنجان قهوه، یک ایده​

قصه‌ی دایجسترا به آن سند ازدواج ختم نمی‌شود.

روزی دایجسترا و ریا، همسر آینده‌اش، در آمستردام خرید کرده بودند. خسته شدند و روی تراس یک کافه نشستند تا قهوه‌ای بنوشند.

نه آزمایشگاهی در کار بود.
نه جلسه‌ای رسمی.
نه تخته‌ای پر از فرمول.
نه جمعی از استادان.

فقط یک روز معمولی بود، یک کافه، یک فنجان قهوه، و ذهنی که از اندیشیدن بازنمی‌ایستاد.

دایجسترا در همان فضا به پرسشی ساده فکر کرد:

کوتاه‌ترین مسیر میان دو شهر چیست؟

مثلاً از روتردام تا خرونینگن.

امروز این پرسش برای ما بدیهی است. مقصد را در نقشه وارد می‌کنیم و چند لحظه بعد، مسیر پیشنهادی را می‌بینیم. اما در آن زمان، تبدیل چنین پرسشی به روشی دقیق و قابل اجرا برای رایانه، کاری تازه و جدی بود.

زیبایی مسئله در سادگی آن بود. هر کسی می‌فهمید کوتاه‌ترین مسیر یعنی چه. اما هنر دایجسترا این بود که پشت این پرسش ساده، ساختاری دقیق دید.

شهرها می‌توانستند نقطه باشند.
راه‌ها می‌توانستند پیوند میان نقطه‌ها باشند.
فاصله‌ها می‌توانستند وزن این پیوندها باشند.

به زبان علوم رایانه، مسئله به یک گراف وزن‌دار تبدیل می‌شد: شبکه‌ای از نقطه‌ها و پیوندها که هر پیوند هزینه یا فاصله‌ای دارد.

پرسش حالا شکل روشن‌تری پیدا کرده بود:

از یک نقطه آغاز کنیم؛ چگونه کوتاه‌ترین راه را تا نقطه‌های دیگر پیدا کنیم؟

طبق روایتی که از خود دایجسترا نقل شده، ایده‌ی این روش در حدود بیست دقیقه به ذهنش رسید.

بیست دقیقه؛ اما نه بیست دقیقه‌ی خالی.

پشت آن لحظه، سال‌ها دقت، تمرین ذهنی و زندگی با مسئله بود. بسیاری از ایده‌های بزرگ ناگهانی به نظر می‌رسند، اما فقط برای ذهنی پدیدار می‌شوند که از پیش آماده‌ی دیدن آن‌هاست.

دایجسترا فقط یک الگوریتم نساخت​

امروز بسیاری از دانشجویان علوم رایانه، دایجسترا را با الگوریتم کوتاه‌ترین مسیر می‌شناسند. الگوریتم، یعنی روشی گام‌به‌گام برای حل یک مسئله. در اینجا مسئله این است که در یک شبکه‌ی وزن‌دار، کوتاه‌ترین مسیر را از یک نقطه به نقطه‌های دیگر پیدا کنیم.

اما اگر دایجسترا را فقط با همین الگوریتم بشناسیم، بخش مهمی از قصه را از دست داده‌ایم.

اهمیت او فقط در ساختن یک روش محاسباتی نبود. اهمیت او در نوع نگاهش بود.

دایجسترا می‌توانست از دل یک پرسش روزمره، مدلی روشن بسازد. مسیرهای واقعی جهان را به شبکه تبدیل کند. فاصله‌ها را به وزن. حرکت میان شهرها را به مسئله‌ای قابل محاسبه. سپس برای آن مسئله، روشی دقیق و فهمیدنی پیشنهاد دهد.

این همان جایی است که برنامه‌نویسی از نوشتن چند دستور فراتر می‌رود.

برنامه‌نویسی، در معنای جدی خود، یعنی دیدن نظم پنهان در مسئله‌ها؛ یعنی ساختن مدلی که هم انسان بتواند آن را بفهمد و هم ماشین بتواند آن را اجرا کند.

برنامه‌نویس فروتن یعنی چه؟​

سال‌ها بعد، دایجسترا سخنرانی معروف خود را با عنوان برنامه‌نویس فروتن ارائه کرد. این عنوان، اگر درست فهمیده شود، یکی از زیباترین توصیف‌ها از کار برنامه‌نویسی است.

فروتنی در اینجا به معنای کوچک شمردن برنامه‌نویس نیست. دایجسترا نمی‌خواست بگوید برنامه‌نویسی کار کم‌ارزشی است. برعکس، او برنامه‌نویسی را کاری چنان جدی می‌دانست که به فروتنی نیاز دارد.

فروتنی یعنی بدانیم ذهن انسان محدود است.
یعنی پیچیدگی را دست‌کم نگیریم.
یعنی خیال نکنیم چون برنامه امروز اجرا شد، پس آن را فهمیده‌ایم.
یعنی از کدی که فقط «به‌زحمت کار می‌کند» راضی نباشیم.

برای دایجسترا، پرسش مهم فقط این نبود که برنامه کار می‌کند یا نه. پرسش مهم‌تر این بود:

آیا می‌توانیم بفهمیم چرا درست کار می‌کند؟

این نگاه هنوز هم تازه است.

در کار روزمره‌ی نرم‌افزار، وسوسه زیاد است: راه‌حلی سریع بنویسیم، چیزی را وصله کنیم، پیچیدگی را عقب بیندازیم، نامی مبهم بگذاریم، ساختاری نامفهوم بسازیم و فقط خوشحال باشیم که برنامه فعلاً اجرا می‌شود.

اما دایجسترا به ما یادآوری می‌کند که «فعلاً کار می‌کند» پایان راه نیست. گاهی تازه آغاز خطر است.

فروتنی در برابر پیچیدگی​

برنامه‌نویس فروتن کسی نیست که اعتمادبه‌نفس ندارد. کسی است که پیچیدگی را جدی می‌گیرد.

او می‌داند سامانه‌های نرم‌افزاری خیلی زود از کنترل ذهن انسان بیرون می‌روند. می‌داند هر نام مبهم، هر شاخه‌ی بی‌دلیل، هر وابستگی پنهان و هر تصمیم شتاب‌زده، می‌تواند فهم برنامه را سخت‌تر کند.

پس تلاش می‌کند کد را روشن‌تر بنویسد.
مسئله را درست‌تر صورت‌بندی کند.
مرزها را دقیق‌تر ببیند.
نام‌ها را با دقت انتخاب کند.
و پیچیدگی را نه پنهان، بلکه مهار کند.

این نگاه، امروز حتی مهم‌تر شده است. ابزارها قدرتمندتر شده‌اند، زبان‌ها پیشرفته‌تر شده‌اند، سامانه‌ها بزرگ‌تر شده‌اند، و حتی هوش مصنوعی می‌تواند برای ما کد تولید کند. اما یک چیز تغییر نکرده است: محدودیت ذهن انسان.

اگر کدی را نفهمیم، مالک واقعی آن نیستیم؛ حتی اگر اجرا شود.

چرا این قصه هنوز زنده است؟​

ممکن است بگوییم این‌ها مربوط به گذشته است. امروز دیگر برنامه‌نویسی شغلی شناخته‌شده است. پس چرا باید هنوز قصه‌ی دایجسترا را خواند؟

چون مسئله فقط نام یک شغل نیست.

هنوز هم کارهای تازه‌ای هستند که در آغاز جدی گرفته نمی‌شوند. هنوز هم نقش‌هایی پدیدار می‌شوند که فرم‌های رسمی، ساختارهای سازمانی و حتی زبان روزمره هنوز برایشان آماده نیست. هنوز هم آدم‌هایی هستند که باید میان مسیر امن و مسیر ناشناخته یکی را انتخاب کنند.

از سوی دیگر، خود برنامه‌نویسی هم نیاز دارد بارها از نو جدی گرفته شود.

هر بار که آن را فقط به تولید کد فرو می‌کاهیم، چیزی از معنای آن را از دست می‌دهیم.
هر بار که پیچیدگی را نادیده می‌گیریم، از روح نگاه دایجسترا دور می‌شویم.
هر بار که به «فعلاً کار می‌کند» قانع می‌شویم، فراموش می‌کنیم برنامه‌نویسی فقط اجرا گرفتن از ماشین نیست.

برنامه‌نویسی یعنی دقیق دیدن مسئله.
یعنی ساختن مدل روشن.
یعنی مهار پیچیدگی.
یعنی نوشتن چیزی که فردا هم بتوان آن را فهمید.

تصویر آخر​

برای من، ماندگارترین تصویر از این قصه، دایجسترا در همان کافه است.

نه روی صحنه‌ی جایزه.
نه پشت تریبون دانشگاه.
نه کنار رایانه‌ای بزرگ در آزمایشگاه.

بلکه در یک روز عادی، پس از خرید، کنار ریا، با یک فنجان قهوه.

مردی که عنوان شغلش را در سند ازدواج نپذیرفته بودند، در سکوت به مسئله‌ای فکر می‌کرد که بعدها میلیون‌ها دانشجو و مهندس آن را خواهند آموخت.

این تصویر دلنشین است، چون نشان می‌دهد تاریخ فناوری همیشه در جاهای پرزرق‌وبرق ساخته نمی‌شود. گاهی در یک گفت‌وگو ساخته می‌شود. گاهی در یک فرم اداری که واژه‌ای تازه را نمی‌پذیرد. گاهی هم روی تراس یک کافه، در میانه‌ی خستگی یک روز معمولی.

دایجسترا فقط برنامه ننویخت. او کمک کرد برنامه‌نویسی به کاری تبدیل شود که بتوان درباره‌اش جدی اندیشید، برایش معیار داشت و آن را بخشی از تفکر علمی و مهندسی دانست.

روزی برنامه‌نویسی آن‌قدر ناشناخته بود که در سند ازدواج جایی نداشت.

امروز جهان بدون برنامه‌نویسی، حتی مسیر خانه تا مقصد را هم به سختی پیدا می‌کند.

و شاید همین، بهترین تصویر از دایجسترا باشد:

مردی که در زمانی برنامه‌نویس شد که برنامه‌نویس بودن، هنوز شغل به حساب نمی‌آمد.

منابع​

• سخنرانی جایزه‌ی تورینگ دایجسترا: The Humble Programmer
• زندگی‌نامه‌ی دایجسترا در مرکز ریاضی و علوم رایانه‌ی هلند
• آرشیو نوشته‌های EWD در دانشگاه تگزاس

من معمولاً همین‌جا تفاوت میان «کار کردن» و «قابل اداره بودن» را می‌بینم. سامانه ممکن است تا حدی زنده باشد، درخواست بگیرد و حتی بیشتر مسیرها را درست پاسخ بدهد، اما در لحظه‌ی تغییر یا اختلال، برای تیم قابل فهم نباشد. قابلیت اداره‌پذیری، یا operability، درباره‌ی همین لحظه‌هاست: لحظه‌هایی که باید بفهمیم چه رخ داده، آسیب را محدود کنیم، تصمیمی امن بگیریم، و اگر لازم شد از مسیر اشتباه برگردیم.

وقتی می‌گویم سامانه قابل اداره است، منظورم فقط این نیست که داشبورد دارد. حتی منظورم این نیست که لاگ، متریک و تریس فراوان تولید می‌کند. منظورم سامانه‌ای است که در زمان ابهام، تیم را با حدس، حافظه‌ی افراد و دستورهای دستی تنها نمی‌گذارد. خطاهایش معنا دارند، وابستگی‌هایش قابل ردگیری‌اند، مسیر بازگشتش تمرین شده، و عملیات تکراری‌اش تا جای ممکن قابل بازبینی و امن شده است.

برای همین من اداره‌پذیری را با مفاهیم نزدیک به آن یکی نمی‌گیرم:

ممکن است سرویس پرداخت پایا باشد و متریک‌های خوبی هم داشته باشد، اما اگر نتوانیم یک درگاه معیوب را موقتاً غیرفعال کنیم، درگاه جایگزین را امن فعال کنیم، یا سفارش‌های نامشخص را بازپردازش کنیم، هنوز با سامانه‌ای سخت‌اداره طرفیم. مشاهده‌پذیری به ما نشان می‌دهد کجا را باید نگاه کنیم؛ اداره‌پذیری می‌پرسد بعد از دیدن، دستمان برای چه کاری باز است.

مشکل بسیاری از سامانه‌ها این نیست که هیچ نشانه‌ای تولید نمی‌کنند؛ مشکل این است که نشانه‌ها به تصمیم وصل نمی‌شوند. هشداری که فقط می‌گوید «خطا زیاد شده است» من را جلو نمی‌برد. من از هشدار خوب انتظار دارم بگوید چه چیزی آسیب دیده، دامنه‌ی اثر کجاست، اقدام نخست چیست، و از کجا می‌فهمیم رخداد تمام شده است.

این نمونه‌ی کوچک، پیکربندی واقعی یک ابزار هشدار نیست. فقط می‌خواهم با آن تفاوت هشدار مبهم و هشدار قابل اقدام را نشان بدهم:

noisy_alert = {
    "name": "errors_are_high",
    "condition": "error_count > 100",
    "suggested_action": "investigate",
}

actionable_alert = {
    "name": "checkout_payment_error_rate_is_high",
    "condition": "checkout_payment_error_rate > 0.05 for 10m",
    "context": {
        "service": "checkout",
        "dependency": "payment_gateway",
        "region": "tehran",
    },
    "user_impact": "users may fail to complete payment",
    "first_safe_action": "enable_fallback_payment_provider",
    "runbook": "runbooks/checkout/payment_degradation.md",
    "recovery_condition": "checkout_payment_error_rate < 0.01 for 20m",
}

در نمونه‌ی دوم، هشدار فقط پرجزئیات‌تر نیست؛ تصمیم‌پذیرتر است. کسی که آن را می‌بیند، بهتر می‌فهمد مشکل به کدام سرویس و وابستگی مربوط است، اثر احتمالی روی کاربر چیست، اقدام نخست کدام است، و چه زمانی می‌توان رخداد را پایان‌یافته دانست.

حالا دوباره به همان سفارش برگردیم. پرداخت موفق شده، اما سفارش در پنل نیست. اگر مسیر داده روشن نباشد، باید حدس بزنیم: آیا پیام order_created دیر به صف رسیده؟ آیا موجودی هنوز به‌روز نشده؟ آیا گزارش مالی پرداخت را دیده اما پنل پشتیبانی سفارش را نه؟ آیا نسخه‌ی تازه قرارداد پیام را تغییر داده و مصرف‌کننده‌ی قدیمی هنوز با شکل جدید پیام سازگار نیست؟

در چنین رخدادی هیچ سرویس واحدی الزاماً «خاموش» نیست. ممکن است همه‌چیز از دید مانیتورینگ زنده باشد، اما روایت کلی سامانه ناقص باشد. این همان جایی است که سامانه‌های داده‌محور سخت‌تر اداره می‌شوند. داده ممکن است دیر برسد، دوبار پردازش شود، از ترتیب خارج شود، یا در چند بخش سامانه چند روایت متفاوت بسازد. کد را شاید بتوان سریع rollback کرد، اما داده‌ی نیمه‌کاره یا ناسازگار ممکن است ساعت‌ها اثر بگذارد.

اینجاست که می‌شود فهمید اداره‌پذیری از طراحی شروع می‌شود، نه از داشبورد. اگر مرز سرویس‌ها مبهم باشد، خرابی راحت از یک بخش به بخش دیگر سرایت می‌کند. اگر خطاها فقط failed یا internal error باشند، نمی‌فهمیم خطا گذراست یا پایدار، تکرار درخواست امن است یا نه، و کدام کاربر آسیب دیده است. اگر rollback فقط روی کاغذ وجود داشته باشد، در زمان بحران به کار نمی‌آید؛ چون باید با داده، صف، کش و نسخه‌های هم‌زمان هم سازگار باشد.

حتی تصمیم‌هایی که ظاهراً کوچک‌اند، در عملیات اثر بزرگ دارند. مهلت انتظار نامناسب می‌تواند زنجیره‌ی درخواست‌ها را قفل کند. تلاش دوباره‌ی بی‌مهار هنگام کندی، بار سامانه را بیشتر می‌کند. نبود اجرای دوباره‌ی امن می‌تواند یک درخواست تکراری را به سفارش یا پرداخت تکراری تبدیل کند. گاهی هم بهترین تصمیم این است که بخشی از قابلیت را موقتاً کم کنیم تا کل مسیر کاربر خراب نشود؛ یعنی کاهش سطح سرویس باید از قبل طراحی شده باشد.

اگر بخواهم این حرف‌ها را به چند عادت عملی تبدیل کنم، از همین‌جا شروع می‌کنم: هر هشدار باید مالک، اثر کاربری، اقدام نخست و معیار پایان داشته باشد. هر استقرار باید مسیر بازگشت تمرین‌شده داشته باشد. هر وابستگی بیرونی باید رفتار مشخصی در کندی، قطعی و پاسخ ناسازگار داشته باشد. هر مسیر داده باید داستان روشنی برای تازگی داده، بازپردازش و اصلاح داده‌ی خراب داشته باشد. هر کار دستی تکراری هم باید یا حذف شود، یا به ابزار امن و قابل بازبینی تبدیل شود.

این‌ها فقط وظیفه‌ی تیم عملیات نیست. تیم مهندسی باید خطا، rollback، تلاش دوباره و رفتار وابستگی‌ها را در طراحی ببیند. تیم پلتفرم باید استقرار، مانیتورینگ، پیکربندی و بازیابی را ساده و امن کند. تیم داده باید تازگی، کیفیت و مسیر داده را قابل پیگیری کند. معماری هم باید مرزها و الگوهای خرابی را در سطح کل سامانه ببیند. اگر این تیم‌ها زبان مشترک نداشته باشند، هرکدام از زاویه‌ی خودشان حرف درستی می‌زنند، اما سامانه همچنان سخت اداره می‌شود.

در پایان، اگر بخواهم همه‌ی بحث را به یک جمله برگردانم، می‌گویم سامانه‌ی قابل اداره الزاماً بی‌خطا نیست؛ تفاوتش این است که وقتی خطا رخ می‌دهد، تیم می‌داند چه چیزی را ببیند، چه چیزی را دست نزند، چه اقدامی امن‌تر است، و از کجا باید برگردد. مانیتورینگ و مشاهده‌پذیری برای رسیدن به این نقطه لازم‌اند، اما کافی نیستند. سامانه‌ی خوب فقط سامانه‌ای نیست که در روزهای عادی کار کند؛ سامانه‌ی خوب سامانه‌ای است که هنگام تغییر و خرابی هم قابل فهم و قابل اداره بماند.

اگر قرار باشد بعد از خواندن این متن فقط چند چیز در ذهن بماند، یکی این است که اداره‌پذیری یعنی توان فهم، تغییر، عیب‌یابی، مهار آسیب و بازیابی سامانه در محیط واقعی. دیگری این است که هشدار خوب باید اثر، دامنه، اقدام نخست و معیار پایان داشته باشد. و شاید مهم‌تر از همه: در سامانه‌های داده‌محور، مسیر داده به‌اندازه‌ی زنده بودن سرویس مهم است.

برای ادامه‌ی مطالعه، کتاب‌ها و نوشته‌هایی مثل Designing Data-Intensive Applications، Site Reliability Engineering، The Site Reliability Workbook، Release It!، Team Guide to Software Operability و Team Topologies نقطه‌ی شروع خوبی هستند.

فرض کنید در یک سامانه‌ی مالی، مهم‌ترین قانون کسب‌وکار این است که فقط کاربرانی که موجودی کافی دارند بتوانند درخواست برداشت ثبت کنند. این قانون، از جنس سیاست اصلی سیستم است؛ یعنی همان چیزی که اگر روزی دیتابیس، فریم‌ورک، یا روش ارتباط با سرویس‌های بیرونی عوض شود، هنوز باید معتبر بماند.

اما در عمل، خیلی وقت‌ها این قانون را مستقیم به جزئیات فنی می‌دوزیم. چیزی شبیه این:

import {PrismaClient} from '@prisma/client'
import axios from 'axios'

const prisma = new PrismaClient()

class WithdrawService {
  async withdraw(userId: string, amount: number) {
    const user = await prisma.user.findUnique({
      where: {id: userId},
    })

    if (!user) {
      throw new Error('User not found')
    }

    if (user.balance < amount) {
      throw new Error('Insufficient balance')
    }

    await axios.post('https://wallet-service.example.com/withdraw', {
      userId,
      amount,
    })

    await prisma.withdrawRequest.create({
      data: {
        userId,
        amount,
        status: 'submitted',
      },
    })
  }
}

در این کد، منطق اصلی برداشت مستقیماً هم به ORM وابسته است، هم به یک کارخواه وب. یعنی مهم‌ترین بخش تصمیم‌گیری سیستم، به چیزهایی وصل شده که در اصل فقط ابزار اجرا هستند.

مسئله فقط این نیست که کد کمی شلوغ شده است. مسئله این است که جهت وابستگی برعکس چیزی است که طراحی خوب می‌خواهد. این‌جا سیاست سطح بالا به جزئیات سطح پایین آویزان شده است.

این همان جایی است که اصل وارونگی وابستگی وارد می‌شود.

مسئله دقیقاً چیست؟​

در مثال بالا، WithdrawService قرار است یک تصمیم مهم بگیرد: آیا برداشت مجاز است یا نه؟ این همان بخش مهم و پایدار سیستم است. اما برای انجام این کار، مستقیماً به PrismaClient و axios چسبیده است.

این وابستگی چند دردسر می‌سازد:

• اگر روش دسترسی به داده عوض شود، منطق اصلی هم باید دست بخورد.
• اگر سرویس بیرونی تغییر کند، باز هم همان کد مهم باید تغییر کند.
• آزمون‌کردن این منطق سخت‌تر می‌شود، چون باید ابزارهای واقعی یا شبیه‌سازی پیچیده را وارد کنیم.
• فهم مرز بین «قانون سیستم» و «روش اجرا» سخت‌تر می‌شود.

یعنی سیاست اصلی، به‌جای اینکه روی پای خودش بایستد، روی شانه‌ی ابزارها ایستاده است.

وارونگی وابستگی چه می‌گوید؟​

اصل وارونگی وابستگی (Dependency Inversion Principle) می‌گوید:

• ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند.
• هر دو باید به انتزاع وابسته باشند.
• انتزاع نباید به جزئیات وابسته باشد.
• جزئیات باید به انتزاع وابسته باشند.

این اصل در ظاهر کمی انتزاعی به نظر می‌رسد، اما معنایش بسیار عملی است: قانون اصلی سیستم نباید بداند دیتابیس دقیقاً چیست، یا درخواست HTTP دقیقاً چگونه ارسال می‌شود.

به‌جای این وابستگی مستقیم، باید یک مرز انتزاعی تعریف کنیم؛ چیزی که سیاست سطح بالا با آن کار کند، و ابزارهای واقعی پشت آن قرار بگیرند.

برگرداندن جهت وابستگی​

بیایید همان مثال برداشت را بازنویسی کنیم. نخست، به‌جای اینکه سرویس مستقیماً سراغ ORM و HTTP برود، دو درگاه تعریف می‌کنیم:

interface UserBalanceReader {
  findById(userId: string): Promise<User | null>
}

interface WithdrawRequestGateway {
  submit(userId: string, amount: number): Promise<void>
  saveRequest(userId: string, amount: number): Promise<void>
}

حالا سیاست اصلی فقط به این انتزاع‌ها وابسته می‌شود:

class WithdrawService {
  constructor(
    private readonly userBalanceReader: UserBalanceReader,
    private readonly withdrawRequestGateway: WithdrawRequestGateway,
  ) {}

  async withdraw(userId: string, amount: number) {
    const user = await this.userBalanceReader.findById(userId)

    if (!user) {
      throw new Error('User not found')
    }

    if (user.balance < amount) {
      throw new Error('Insufficient balance')
    }

    await this.withdrawRequestGateway.submit(userId, amount)
    await this.withdrawRequestGateway.saveRequest(userId, amount)
  }
}

در این نسخه، منطق اصلی دیگر نمی‌داند Prisma چیست یا axios چه می‌کند. او فقط با قراردادهایی کار می‌کند که برای نیاز خودش تعریف شده‌اند.

حالا پیاده‌سازی‌های فنی به این قراردادها وابسته می‌شوند:

import {PrismaClient} from '@prisma/client'
import axios from 'axios'

const prisma = new PrismaClient()

class PrismaUserBalanceReader implements UserBalanceReader {
  async findById(userId: string) {
    return prisma.user.findUnique({
      where: {id: userId},
    })
  }
}

class WalletWithdrawGateway implements WithdrawRequestGateway {
  async submit(userId: string, amount: number) {
    await axios.post('https://wallet-service.example.com/withdraw', {
      userId,
      amount,
    })
  }

  async saveRequest(userId: string, amount: number) {
    await prisma.withdrawRequest.create({
      data: {
        userId,
        amount,
        status: 'submitted',
      },
    })
  }
}

حالا جهت وابستگی عوض شده است. قبلاً منطق اصلی به ابزارها وابسته بود. حالا ابزارها به قراردادی وابسته‌اند که منطق اصلی تعیین کرده است.

این همان وارونگی وابستگی است.

چرا این اصل مهم است؟​

شاید در پروژه‌ی کوچک، این‌همه مرزبندی اضافه به نظر برسد. اما وقتی سیستم رشد می‌کند، اهمیت این اصل روشن می‌شود.

۱. تغییر ابزار، قانون اصلی را تکان نمی‌دهد​

اگر امروز از Prisma استفاده می‌کنید و فردا سراغ ابزار دیگری می‌روید، یا اگر امروز با HTTP به یک سرویس بیرونی وصل می‌شوید و فردا از صف پیام استفاده می‌کنید، نباید لازم باشد قانون برداشت را بازنویسی کنید.

سیاست اصلی باید تا حد ممکن از این تغییرها مصون بماند.

۲. آزمون‌پذیری بهتر می‌شود​

وقتی سرویس اصلی به انتزاع وابسته باشد، آزمون‌کردن آن خیلی ساده‌تر می‌شود:

class FakeUserBalanceReader implements UserBalanceReader {
  async findById(userId: string) {
    return {id: userId, balance: 1_000_000}
  }
}

class FakeWithdrawRequestGateway implements WithdrawRequestGateway {
  submitted: Array<{userId: string; amount: number}> = []

  async submit(userId: string, amount: number) {
    this.submitted.push({userId, amount})
  }

  async saveRequest(userId: string, amount: number) {
    return
  }
}

و آزمون هم ساده می‌شود:

test('submits withdraw request when balance is sufficient', async () => {
  const userReader = new FakeUserBalanceReader()
  const gateway = new FakeWithdrawRequestGateway()
  const service = new WithdrawService(userReader, gateway)

  await service.withdraw('user-1', 100_000)

  expect(gateway.submitted).toEqual([
    {userId: 'user-1', amount: 100_000},
  ])
})

در این آزمون، نه ORM واقعی در کار است، نه HTTP واقعی، نه وابستگی به محیط بیرونی. ما فقط قانون اصلی را می‌سنجیم.

۳. مرز معماری روشن‌تر می‌شود​

وقتی جهت وابستگی درست باشد، خیلی بهتر می‌فهمیم کدام بخش از سیستم «هسته» است و کدام بخش «ابزار». این تمایز فقط سلیقه‌ی معماری نیست؛ کمک می‌کند تصمیم‌های فنی را در جای درست بگیریم.

انتزاع را چه کسی باید تعریف کند؟​

نکته‌ی مهم این است که انتزاع معمولاً باید نزدیک به نیاز سیاست سطح بالا تعریف شود، نه نزدیک به ابزار.

مثلاً اگر سرویس برداشت فقط نیاز دارد کاربر را پیدا کند و درخواست برداشت ثبت کند، انتزاع هم باید همین نیاز را بازتاب دهد. نه اینکه از همان ابتدا درگاه‌هایی بسازیم که بوی دیتابیس یا HTTP بدهند.

برای نمونه، این قرارداد خوب نیست:

interface PrismaCompatibleRepository {
  findUnique(query: unknown): Promise<unknown>
  create(data: unknown): Promise<unknown>
}

چون این دیگر انتزاع واقعی نیست؛ فقط نام دیتابیس را پنهان کرده‌ایم. سیاست سطح بالا هنوز عملاً به منطق ابزار وابسته است.

در عوض، این بهتر است:

interface UserBalanceReader {
  findById(userId: string): Promise<User | null>
}

چون بر پایه‌ی نیاز کسب‌وکار تعریف شده، نه بر پایه‌ی شکل ابزار.

این اصل با معماری تمیز چه نسبتی دارد؟​

اصل وارونگی وابستگی یکی از ستون‌های اصلی معماری تمیز (Clean Architecture) است. در معماری تمیز، لایه‌های درونی که منطق اصلی سیستم را در خود دارند، نباید به لایه‌های بیرونی وابسته باشند. لایه‌های بیرونی باید خودشان را با نیاز هسته سازگار کنند.

یعنی اگر هسته‌ی سیستم بگوید «من برای خواندن موجودی، چنین قراردادی می‌خواهم»، این دیتابیس و وب و چارچوب‌اند که باید خودشان را با این قرارداد وفق دهند، نه برعکس.

به همین دلیل است که در طراحی تمیز، خیلی وقت‌ها درگاه‌ها یا واسط‌ها در بخش درونی‌تر تعریف می‌شوند، اما پیاده‌سازی آن‌ها در لایه‌های بیرونی قرار می‌گیرد.

آیا همیشه باید برای همه‌چیز انتزاع بسازیم؟​

نه. این هم یکی از جاهایی است که می‌شود افراط کرد.

اگر برای هر چیز کوچک، بی‌دلیل چندین لایه‌ی انتزاعی بسازیم، طراحی ممکن است بی‌جهت سنگین شود. اصل وارونگی وابستگی قرار نیست ما را وادار کند که برای هر تابع ساده یک اینترفیس جدا تعریف کنیم.

این اصل زمانی بیشترین ارزش را دارد که:

• با یک سیاست مهم و پایدار طرف هستیم
• ابزارهای بیرونی امکان تغییر دارند
• آزمون‌پذیری مهم است
• وابستگی مستقیم به ابزار، هزینه‌ی تغییر بالایی ایجاد می‌کند

پس هدف، انتزاع‌سازی افراطی نیست؛ هدف، محافظت از هسته‌ی مهم سیستم در برابر جزئیات ناپایدار است.

یک نمونه از ساختار پوشه​

اگر این مرزبندی را در ساختار پروژه نشان دهیم، شاید چیزی شبیه این داشته باشیم:

withdraw/
  application/
    withdraw-service.ts
    user-balance-reader.ts
    withdraw-request-gateway.ts
  infrastructure/
    prisma-user-balance-reader.ts
    wallet-withdraw-gateway.ts

در این ساختار:

• application محل منطق اصلی و قراردادهای موردنیاز آن است.
• infrastructure محل پیاده‌سازی‌های وابسته به ابزارهاست.

این یعنی هسته‌ی سیستم می‌گوید «من چه می‌خواهم»، و زیرساخت می‌گوید «من آن را چگونه اجرا می‌کنم».

پیشنهاد عملی​

اگر می‌خواهی اصل وارونگی وابستگی را در یک کد موجود بررسی کنی، از جاهایی شروع کن که منطق مهم سیستم مستقیم با ابزارها حرف می‌زند.

چیزهایی که باید بررسی شوند:

• آیا یک سرویس کسب‌وکار مستقیم ORM، HTTP client، صف پیام یا چارچوب وب را صدا می‌زند؟
• آیا تغییر ابزارهای زیرساختی، فایل‌های مربوط به قانون‌های اصلی را هم مجبور به تغییر می‌کند؟
• آیا آزمون منطق اصلی بدون راه‌اندازی ابزارهای بیرونی سخت است؟
• آیا می‌توان نیاز واقعی سیاست سطح بالا را با یک درگاه کوچک و روشن بیان کرد؟
• آیا انتزاع‌های فعلی واقعاً زبان کسب‌وکار دارند یا فقط شکل ابزار را پنهان کرده‌اند؟

چیزهایی که نباید بی‌دلیل تغییر کنند:

• کدهای ساده‌ای که هنوز با ابزار بیرونی درگیر نیستند
• جاهایی که ساخت انتزاع فقط پیچیدگی تزئینی می‌سازد
• قراردادهای خوب و کوچکی که همین حالا هم بر پایه‌ی نیاز واقعی تعریف شده‌اند
• منطق اصلی‌ای که از قبل از جزئیات جدا شده و مرز درستی دارد

برای اعتبارسنجی تغییر، دست‌کم این گام‌ها را اجرا کنید:

npm test
npm run lint
npm run typecheck

اگر پروژه‌ی شما این فرمان‌ها را ندارد، معادل آن‌ها را اجرا کنید. بهتر است علاوه بر آزمون‌های کلی، برای خود سیاست سطح بالا هم آزمون‌هایی داشته باشید که بدون ORM، بدون HTTP واقعی، و بدون وابستگی به چارچوب اجرا شوند. اگر چنین آزمون‌هایی ساده شده‌اند، احتمال زیادی دارد که جهت وابستگی را درست برگردانده باشید.

جمع‌بندی​

اصل وارونگی وابستگی می‌گوید کد مهم‌تر نباید به کد کم‌اهمیت‌تر وابسته باشد. این حرف در ظاهر ساده است، اما اثر بزرگی روی طراحی دارد. چون بسیاری از دردهای نگه‌داری، از همین‌جا آغاز می‌شوند که منطق اصلی سیستم را به ابزارهایی می‌دوزیم که باید صرفاً نقش اجرایی داشته باشند.

دیتابیس، HTTP، صف پیام، ORM و فریم‌ورک مهم‌اند، اما نه به‌اندازه‌ی قانون اصلی سیستم. این‌ها باید در خدمت هسته باشند، نه اینکه هسته را کنترل کنند.

طراحی خوب، جهت وابستگی را طوری می‌چیند که سیاست‌های اصلی پابرجا بمانند و جزئیات دور آن‌ها بچرخند. اصل وارونگی وابستگی دقیقاً همین را به ما یادآوری می‌کند: هسته باید تعیین کند چه می‌خواهد؛ ابزارها باید خودشان را با هسته سازگار کنند.

فرض کنید در یک سامانه‌ی مالی، یک ریپازیتوری بزرگ برای کار با تراکنش‌ها داریم. این ریپازیتوری همه‌چیز را با هم دارد: گرفتن تراکنش، ساخت گزارش، بستن حساب، بازسازی داده، خروجی گرفتن، و چند کار دیگر. روی کاغذ، شاید این طراحی «مرکزی» و «یک‌پارچه» به نظر برسد. اما کافی است یک مصرف‌کننده‌ی کوچک وارد ماجرا شود تا مشکل خودش را نشان دهد.

برای نمونه، یک سرویس داریم که فقط می‌خواهد یک تراکنش را بر اساس شناسه پیدا کند:

interface TransactionRepository {
  findById(id: string): Promise<Transaction | null>
  save(transaction: Transaction): Promise<void>
  delete(id: string): Promise<void>
  exportDailyReport(date: string): Promise<ReportFile>
  rebuildBalances(): Promise<void>
  closeMonth(month: string): Promise<void>
  archiveOldTransactions(before: string): Promise<number>
}

و مصرف‌کننده‌ی ما فقط همین را لازم دارد:

class TransactionDetailsService {
  constructor(
    private readonly repository: TransactionRepository,
  ) {}

  async getDetails(id: string) {
    return this.repository.findById(id)
  }
}

در نگاه نخست، شاید کسی بگوید: «خب چه اشکالی دارد؟ این سرویس که فقط از findById استفاده می‌کند.» اما مسئله دقیقاً همین‌جاست. این سرویس، حتی اگر فقط به یک متد نیاز داشته باشد، به اینترفیس بزرگی وابسته شده که پر از چیزهای نامربوط است. یعنی یک کلاس کوچک، ناخواسته بار یک قرارداد بزرگ را روی دوش می‌کشد.

این‌جا پای یکی از مهم‌ترین اصل‌های طراحی به میان می‌آید: اصل جداسازی اینترفیس.

مشکل فقط زیادی‌بودن متدها نیست​

وقتی از اینترفیس بزرگ حرف می‌زنیم، مسئله فقط این نیست که تعداد متدها زیاد است. مشکل اصلی این است که وابستگی کاذب می‌سازیم. یعنی کلاسی که فقط به یک قابلیت نیاز دارد، در ظاهر به مجموعه‌ای از قابلیت‌های دیگر هم وابسته می‌شود؛ قابلیت‌هایی که نه آن‌ها را صدا می‌زند، نه باید درباره‌شان چیزی بداند.

این وابستگی پنهان معمولاً سه پیامد مهم دارد:

1. تغییر پرهزینه‌تر می‌شود.
2. آزمون‌نویسی سخت‌تر می‌شود.
3. مرز مسئولیت‌ها مبهم‌تر می‌شود.

بیایید هرکدام را روشن‌تر ببینیم.

وابستگی پنهان چگونه ساخته می‌شود؟​

در مثال بالا، TransactionDetailsService فقط به findById نیاز دارد. اما چون این متد در دل یک اینترفیس بزرگ قرار گرفته، هر تغییری در تعریف آن اینترفیس می‌تواند روی این سرویس هم اثر بگذارد، حتی اگر آن تغییر هیچ ربط مستقیمی به نیاز این سرویس نداشته باشد.

برای نمونه، فرض کنید تیم دیگری تصمیم بگیرد exportDailyReport باید یک پارامتر تازه بگیرد، یا closeMonth قرارداد متفاوتی پیدا کند. اگر در پروژه‌ی شما پیاده‌سازی‌های آزمایشی، ماک‌ها، یا کلاس‌های ساختگی بر اساس این اینترفیس ساخته شده باشند، ناگهان مصرف‌کننده‌ای که فقط findById می‌خواست هم درگیر می‌شود.

یعنی تغییر در بخشی که برای او بی‌ربط است، او را هم تکان می‌دهد.

آزمون‌ها چرا سخت‌تر می‌شوند؟​

یکی از جاهایی که این مشکل خیلی زود خودش را نشان می‌دهد، آزمون‌ها هستند.

اگر بخواهیم TransactionDetailsService را آزمون کنیم، منطقی است که فقط لازم باشد رفتار findById را کنترل کنیم. اما اگر از یک اینترفیس بزرگ استفاده می‌کنیم، ساختن یک پیاده‌سازی آزمایشی از آن می‌تواند آزاردهنده شود.

مثلاً ممکن است در آزمون مجبور شویم چنین چیزی بسازیم:

class FakeTransactionRepository implements TransactionRepository {
  async findById(id: string) {
    return {id, amount: 1000}
  }

  async save(transaction: Transaction) {
    throw new Error('not implemented')
  }

  async delete(id: string) {
    throw new Error('not implemented')
  }

  async exportDailyReport(date: string) {
    throw new Error('not implemented')
  }

  async rebuildBalances() {
    throw new Error('not implemented')
  }

  async closeMonth(month: string) {
    throw new Error('not implemented')
  }

  async archiveOldTransactions(before: string) {
    throw new Error('not implemented')
  }
}

این کد بوی خوبی نمی‌دهد. چرا برای آزمون سرویسی که فقط یک داده را می‌خواند، باید شش متد بی‌ربط دیگر را هم پر کنیم؟ حتی اگر با throw new Error پر شوند، باز هم نشان می‌دهد که قرارداد ما برای این مصرف‌کننده بیش از حد بزرگ است.

مشکل فقط زشتی کد آزمایشی نیست. این وضعیت به ما می‌گوید طراحی اصلی هم مرز روشنی ندارد. آزمون‌ها معمولاً خیلی زودتر از کد تولیدی، اشکال در مرزبندی را لو می‌دهند.

تغییر پرهزینه‌تر یعنی چه؟​

هزینه‌ی تغییر فقط به اندازه‌ی خط‌های جدیدی که می‌نویسیم نیست. بخشی از هزینه، از جاهایی می‌آید که ناخواسته درگیر می‌شوند.

اگر اینترفیس بزرگ باشد، هر بار که یکی از متدهای آن تغییر می‌کند، باید این چیزها را دوباره بررسی کنیم:

• همه‌ی پیاده‌سازی‌های اینترفیس
• همه‌ی ماک‌ها و فیک‌ها
• همه‌ی مصرف‌کننده‌هایی که از روی نام اینترفیس به آن وابسته‌اند
• همه‌ی جاهایی که به‌ظاهر از اینترفیس استفاده می‌کنند، حتی اگر فقط یک متد را لازم داشته باشند

یعنی هزینه‌ی تغییر، از مرز نیاز واقعی فراتر می‌رود. این همان چیزی است که طراحی خوب باید از آن جلوگیری کند.

یک مثال واقعی‌تر: وابستگی مدیریتی در یک سرویس کوچک​

فرض کنید یک کنترلر وب فقط می‌خواهد وضعیت یک کاربر را نشان دهد:

interface UserService {
  getUserProfile(userId: string): Promise<UserProfile>
  updateUserProfile(userId: string, data: UpdateProfileInput): Promise<void>
  resetPassword(userId: string): Promise<void>
  suspendUser(userId: string): Promise<void>
  exportUsersCsv(): Promise<string>
  rebuildSearchIndex(): Promise<void>
}

کنترلر فقط از این استفاده می‌کند:

class UserProfileController {
  constructor(private readonly userService: UserService) {}

  async show(userId: string) {
    return this.userService.getUserProfile(userId)
  }
}

اما حالا این کنترلر، از نظر قراردادی، به بازنشانی گذرواژه، تعلیق کاربر، خروجی گرفتن، و بازسازی نمایه‌ی جست‌وجو هم وابسته شده است. این وابستگی شاید در کد روزمره دیده نشود، اما در معماری، در آزمون، و در هزینه‌ی تغییر کاملاً واقعی است.

راه بهتر: اینترفیس را از نگاه مصرف‌کننده ببینیم​

راه‌حل معمولاً این نیست که صرفاً اینترفیس را «تمیزتر» کنیم یا متدها را گروه‌بندی ظاهری بدهیم. راه‌حل اصلی این است که اینترفیس را از زاویه‌ی مصرف‌کننده ببینیم.

در مثال نخست، اگر TransactionDetailsService فقط به خواندن تراکنش نیاز دارد، شاید این قرارداد برای او کافی باشد:

interface TransactionReader {
  findById(id: string): Promise<Transaction | null>
}

و اگر بخشی دیگر مسئول ذخیره‌سازی است، قرارداد خودش را داشته باشد:

interface TransactionWriter {
  save(transaction: Transaction): Promise<void>
  delete(id: string): Promise<void>
}

قابلیت‌های مدیریتی یا پردازش‌های سنگین هم می‌توانند اینترفیس‌های جداگانه‌ی خودشان را داشته باشند:

interface TransactionReportExporter {
  exportDailyReport(date: string): Promise<ReportFile>
}

interface TransactionMaintenanceService {
  rebuildBalances(): Promise<void>
  closeMonth(month: string): Promise<void>
  archiveOldTransactions(before: string): Promise<number>
}

حالا سرویس جزئیات فقط به چیزی وابسته می‌شود که واقعاً لازم دارد:

class TransactionDetailsService {
  constructor(
    private readonly reader: TransactionReader,
  ) {}

  async getDetails(id: string) {
    return this.reader.findById(id)
  }
}

این طراحی ساده‌تر است، اما مهم‌تر از آن، صادقانه‌تر است. چون وابستگی را همان‌طور که هست نشان می‌دهد؛ نه بیشتر.

این اصل با اصل مسئولیت یکتا هم‌خانواده است​

اصل جداسازی اینترفیس از نظر روح کلی، به اصل مسئولیت یکتا نزدیک است. آن‌جا می‌گفتیم یک واحد نرم‌افزاری نباید چند محور تغییر نامرتبط را با هم حمل کند. این‌جا می‌گوییم یک مصرف‌کننده نباید بار قراردادهایی را بکشد که به آن‌ها نیاز ندارد.

هر دو اصل، در نهایت دارند از یک چیز محافظت می‌کنند: مرز روشن.

وقتی مرزها روشن باشند:

• مصرف‌کننده فقط همان چیزی را می‌بیند که باید ببیند،
• تغییرها محدودتر می‌شوند،
• آزمون‌ها ساده‌تر می‌شوند،
• و طراحی، کمتر به‌سمت وابستگی‌های پنهان می‌رود.

آیا همیشه باید اینترفیس را خرد کنیم؟​

نه. این هم یکی از جاهایی است که اگر بی‌دقت باشیم، از آن‌طرف بام می‌افتیم.

گاهی یک اینترفیس چند متد دارد، اما همه‌ی متدها واقعاً به هم نزدیک‌اند و تقریباً همه‌ی مصرف‌کننده‌ها به بیشتر آن‌ها نیاز دارند. در این حالت، شکستن اینترفیس به چند بخش مصنوعی فقط طراحی را پراکنده‌تر می‌کند.

پس معیار، صرفاً تعداد متدها نیست. معیار این است که آیا مصرف‌کننده‌های متفاوت، زیرمجموعه‌های متفاوتی از متدها را لازم دارند یا نه.

اگر پاسخ مثبت است، احتمال خوبی دارد که اینترفیس بیش از حد پهن شده باشد.

یک نشانه‌ی مهم: متدهای not implemented​

یکی از نشانه‌های بسیار مهم نقض این اصل، این است که پیاده‌سازی‌ها یا کلاس‌های آزمایشی ناچار می‌شوند بعضی متدها را با چیزی شبیه این پر کنند:

throw new Error('not implemented')

یا:

throw new Error('not supported')

یا حتی:

return null

فقط برای اینکه امضای اینترفیس را کامل کرده باشند.

این وضعیت معمولاً یعنی این کلاس، مصرف‌کننده، یا پیاده‌سازی، اصلاً نباید به آن بخش از قرارداد وابسته می‌بود. یعنی اینترفیس برای او بزرگ‌تر از حد لازم است.

یک نمونه از شکستن درست اینترفیس​

فرض کنید ابتدا چنین ساختاری داشتیم:

transactions/
  transaction-repository.ts
  transaction-details-service.ts
  daily-report-service.ts
  month-close-service.ts