انتخاب معماری نرم‌افزار با هوش مصنوعی: از «بستگی دارد» تا تصمیمِ مکتوب
مونولیت یا میکروسرویس، کدام زبان و چارچوب، کدام پایگاه‌داده؛ این راهنما نشان می‌دهد چطور سؤالِ معماری را طوری به چند مدل بدهی که به جایِ جوابِ کلیشه‌ای، معامله‌هایِ واقعی را ببینی.
انتخاب معماری نرم‌افزار با هوش مصنوعی وقتی جواب می‌دهد که از مدل‌ها «بهترین معماری» را نپرسی، بلکه قیدهایِ واقعیِ پروژه‌ات را بدهی و بخواهی گزینه‌ها را زیرِ همان قیدها بسنجند. یک مدل به‌تنهایی معمولاً یا جوابِ کلیِ «بستگی دارد» می‌دهد یا سراغِ گزینه‌ی پرطرفدارِ روز می‌رود. چند مدل که هر کدام از یک گزینه دفاع کنند و ضعفِ بقیه را پیدا کنند، معامله‌ها را روشن‌تر نشان می‌دهند؛ تصمیمِ آخر همچنان با توست، اما این بار با دلیلِ مکتوب.
چرا «بستگی دارد» جوابِ غلطی نیست، ولی کافی هم نیست
معماری تقریباً همیشه معامله است: هر انتخاب چیزی می‌خرد و بهایش را جایِ دیگری می‌پردازد. میکروسرویس، یعنی شکستنِ سیستم به چند سرویسِ کوچکِ مستقل، استقرار و مقیاس‌پذیریِ جداگانه‌ی هر بخش را می‌خرد و بهایش را با فراخوانی‌هایِ شبکه‌ای، سخت شدنِ یکپارچگیِ داده بینِ سرویس‌ها، ردیابیِ خطا در چند جا و بارِ عملیاتیِ بیشتر می‌پردازد. مونولیت، یعنی یک برنامه‌ی واحد با یک استقرار، سادگی، تراکنشِ یکجا و بازآراییِ آسان را می‌خرد و وقتی تیم بزرگ می‌شود و استقرارها به هم گره می‌خورند، بهایش را می‌پردازد.
پس «بستگی دارد» درست است؛ مشکل این است که نمی‌گوید به چه. وقتی سؤالِ کلی از یک مدل می‌پرسی، دو سوگیری جوابش را می‌کشد. اول، متن‌هایی که مدل از آن‌ها یاد گرفته پر از نوشته‌هایی است که گزینه‌هایِ پرسروصدا را ستایش می‌کنند، پس جواب به سمتِ مدِ روز می‌رود. دوم، اگر در سؤالت تمایلت پیداست («می‌خواهم میکروسرویس کار کنم، خوب است؟»)، مدل احتمالاً با تو همراه می‌شود. راهِ فرار از هر دو، دادنِ قیدهایِ مشخص و نشاندنِ صدایِ مخالف سرِ میز است.
قدمِ اولِ انتخاب معماری نرم‌افزار با هوش مصنوعی: قیدها را بنویس
یک سؤالِ معماریِ خوب بیشتر شبیهِ یک صفحه شرحِ وضعیت است تا یک جمله. این‌ها را صادقانه بنویس:
- تیم: چند نفرید، در چه زبان و ابزاری واقعاً تجربه دارید، و چه کسی سیستم را وقتی نیمه‌شب از کار افتاد نگه می‌دارد.
- بار: بارِ مورد انتظارِ واقعی، نه آرزو؛ و الگویش: یکنواخت است یا در ساعت‌ها و روزهایِ خاص جهش دارد؟
- زمان: نسخه‌ی اول کِی باید دستِ کاربر برسد و بعد از آن چقدر فرصتِ بازآرایی دارید.
- مرزهایِ دامنه: بخش‌هایِ سیستم واقعاً مستقل‌اند یا مدام به داده‌هایِ هم سر می‌زنند؟
- سازگاریِ داده: کجا همه‌چیز باید در همان لحظه یکسان باشد (پول، موجودی، رزرو) و کجا چند ثانیه تأخیر اشکالی ندارد (آمار، اعلان).
- زیرساخت: کجا مستقر می‌کنید، چه سرویس‌هایِ آماده‌ای در دسترس دارید و چه محدودیتی رویِ نگه‌داریِ داده هست.
- میراث: کدِ موجود، داده‌ای که باید منتقل شود، و تعهدهایی که نمی‌شود شکست.
در چندهوش پیش از شروع می‌توانی «تأییدِ فرض‌ها» را بزنی تا فرض‌هایِ پنهانِ سؤالت فهرست شوند و تو هر کدام را بپذیری یا رد کنی. در سؤال‌هایِ معماری این مرحله خیلی به کار می‌آید، چون فرض‌هایی مثلِ «به‌زودی کاربرانِ خیلی زیادی خواهید داشت» یا «تیم با کانتینر و ابزارهایِ مدیریتِ آن راحت است» بی‌صدا جواب را عوض می‌کنند. «بررسیِ برداشتِ ما» هم کمک می‌کند مطمئن شوی سؤال همان‌طور که منظورت بوده فهمیده شده. سندِ نیازمندی‌ها را به‌صورتِ PDF پیوست کن، اگر نمونه‌ی اولیه داری مخزنِ گیت‌هابش را وصل کن، و برآوردِ بار را در یک فایلِ Excel یا CSV بگذار.
سه تصمیمی که بیشتر رویِ میز می‌آیند
مونولیت، مونولیتِ ماژولار یا میکروسرویس
بینِ این دو سرِ طیف، گزینه‌ی سومی هست که اغلب نادیده می‌ماند: مونولیتِ ماژولار. یک برنامه با یک استقرار، اما با ماژول‌هایی که مرزِ روشن دارند؛ هر ماژول جدول‌هایِ خودش را دارد و فقط از راهِ رابطِ مشخص با بقیه حرف می‌زند، نه با سرک کشیدن به داده‌هایِ آن‌ها. این انتخاب سادگیِ مونولیت را نگه می‌دارد و درِ جدا کردنِ یک ماژول در آینده را باز می‌گذارد.
برایِ تیم‌هایِ کوچک و محصولِ تازه، توصیه‌ی رایجِ مهندسی شروع از همین نقطه است، مگر دلیلِ محکمی برایِ جدا کردن وجود داشته باشد: بخشی که بارش با بقیه خیلی فرق دارد، یا تیم‌هایِ جدا با زمان‌بندیِ انتشارِ جدا. یک اصلِ شناخته‌شده هم می‌گوید ساختارِ سیستم‌ها معمولاً شبیهِ ساختارِ ارتباطیِ تیمی می‌شود که آن را می‌سازد؛ یعنی سه سرویسِ جدا برایِ یک تیمِ دونفره اغلب فقط مرزهایی می‌سازد که کسی نیازی به آن‌ها نداشت. سؤالِ خوب برایِ میز این است: «کدام بخش واقعاً باید مستقل مستقر شود، و چه نشانه‌ای ثابت می‌کند که وقتش رسیده؟»
انتخابِ زبان و چارچوب
در انتخابِ استک (مجموعه‌ی زبان، چارچوب و ابزارها)، دانشِ فعلیِ تیم معمولاً از هر مقایسه‌ی فنی مهم‌تر است. بعد از آن، کتابخانه‌هایِ آماده برایِ دامنه‌ی خاصِ تو، امکانِ پیدا کردنِ نیرو و بلوغِ ابزارها برایِ نگه‌داریِ بلندمدت می‌آیند. به جایِ «فلان چارچوب بهتر است یا بهمان؟» از میز بپرس: «با این نیازمندی‌ها، در هر گزینه کدام کار سخت‌تر از حدِ انتظار خواهد بود؟» این سؤال مدل‌ها را از فهرستِ کلیِ مزیت‌ها بیرون می‌کشد.
پایگاه‌داده
برایِ داده‌ای که تراکنش و رابطه دارد، پایگاه‌داده‌ی رابطه‌ای انتخابِ پیش‌فرضِ امنی است. ذخیره‌سازِ سندمحور وقتی معنا دارد که شکلِ داده واقعاً متغیر است، نه فقط چون طراحیِ جدول حوصله می‌خواهد. پایگاه‌داده را برایِ مقیاسی که هنوز نداری انتخاب نکن؛ لایه‌ی کش و جدا کردنِ خواندن از نوشتن را می‌شود بعداً اضافه کرد، اما عوض کردنِ خودِ پایگاه‌داده یکی از پرهزینه‌ترین جابه‌جایی‌هاست.
کدام نوعِ نشست برایِ کدام سؤالِ معماری
در انتخاب معماری نرم‌افزار با هوش مصنوعی، شکلِ سؤال تعیین می‌کند کدام قالبِ نشست بیشترین کمک را می‌کند:
| شکلِ سؤال | نوعِ نشست | چرا |
|---|---|---|
| دو گزینه‌ی مشخص، مثلاً مونولیت یا میکروسرویس | مناظره | صندلی‌ها به موافق و مخالف تقسیم می‌شوند و داورِ مستقل می‌گوید کدام طرف قوی‌تر بود. |
| سه یا چند گزینه‌ی رقیب، مثلاً سه استکِ متفاوت | آرنا | هر صندلی مدافعِ یک پیشنهاد است و بعد از هر دورِ نقد، با رأیِ روشن یکی حذف می‌شود تا برنده بماند. |
| طرحی آماده که می‌خواهی حفره‌هایش را پیدا کنی | راستی‌آزمایی | صندلی‌ها مستقل طرح را وارسی می‌کنند و حکم درست، نادرست یا تا حدی درست است. |
| هنوز گزینه‌ای نداری | تولیدِ ایده‌ی عمیق | هدف گزینه‌هایِ متنوعی است که رویِ هم ساخته می‌شوند، نه یک تصمیم. |
| فقط می‌خواهی ببینی هر مدل خودش چه می‌گوید | مقایسه‌ی خالص | بدونِ بحث و داور، جوابِ کاملِ هر صندلی کنارِ هم نشان داده می‌شود. |
| مطمئن نیستی | هوشمندِ هدایتگر | چندهوش خودش قالبِ مناسب را برایِ موضوع انتخاب می‌کند. |
اگر با قالبِ مناظره آشنا نیستی، مناظره هوش مصنوعی توضیح می‌دهد طرف‌ها چطور چیده می‌شوند و داور به چه چیزی نگاه می‌کند.
یک نمونه‌ی فرضی: آرنا برایِ سامانه‌ی رزروِ باشگاه‌ها
این بخش نمونه‌ی فرضی است و فقط شکلِ کار را نشان می‌دهد؛ نشست، تیم و نتیجه‌ی واقعی نیست.
فرض کن تیمی سه‌نفره، با یک برنامه‌نویسِ بک‌اند، می‌خواهد سامانه‌ی رزروِ آنلاین برایِ چند باشگاهِ ورزشی بسازد: رزروِ سانس، پرداخت، پیامکِ یادآوری و پنلِ مدیریت. نسخه‌ی اول باید ظرفِ سه ماه آماده شود و بار در روزهایِ اولِ هر ماه، که ثبت‌نام‌ها باز می‌شود، جهش دارد.
- نوعِ نشست: «آرنا» با سه صندلی از خانواده‌هایِ مختلف، هر کدام مدافعِ یک پیشنهاد: مونولیتِ ماژولار؛ میکروسرویس با سرویس‌هایِ جدا برایِ رزرو، پرداخت و اعلان؛ و مونولیت به‌علاوه‌ی تابع‌هایِ بدونِ سرور (serverless، یعنی کدی که فقط هنگامِ نیاز اجرا می‌شود) برایِ کارهایِ جانبی مثلِ ارسالِ پیامک.
- نقش‌ها: با قالبِ «برنامه‌نویسی»؛ صندلیِ اول معمار، دومی ایده‌پرداز و سومی عمل‌گرا.
- عمق: «عمیق»؛ چون در آرنا بعد از هر دورِ نقد ممکن است یک پیشنهاد حذف شود، عمقِ بیشتر یعنی فرصتِ بیشتر برایِ سنجیدنِ پیشنهادها پیش از اعلامِ برنده.
- پیوست‌ها: سندِ نیازمندی‌ها به‌صورتِ PDF، فایلِ CSV از الگویِ رزروها در طولِ ماه، و مخزنِ گیت‌هابِ نمونه‌ی اولیه.
- پیش از شروع: در «تأییدِ فرض‌ها» فرضِ «تیم با کانتینر و ابزارهایِ مدیریتِ آن تجربه دارد» را رد می‌کنی.
حکمِ نوشته‌شده در این نمونه می‌تواند چنین باشد:
- برنده: مونولیتِ ماژولار. پیشنهادِ میکروسرویس در دورِ اول حذف می‌شود، چون با یک برنامه‌نویسِ بک‌اند و بدونِ تجربه‌ی کانتینر، بارِ عملیاتی‌اش از سودش بیشتر است.
- توافق: رزرو و پرداخت باید در یک تراکنشِ پایگاه‌داده بمانند تا یک سانس دو بار فروخته نشود؛ جهشِ اولِ ماه با یک صفِ کارهایِ پس‌زمینه برایِ اعلان‌ها و بزرگ‌تر کردنِ موقتِ سرور مدیریت‌پذیر است.
- اختلاف: این‌که ارسالِ پیامک از همین حالا تابعِ جدا باشد یا کاری پس‌زمینه داخلِ همان برنامه. حکم هر دو را قابلِ قبول می‌داند و دومی را برایِ سادگی ترجیح می‌دهد.
- قوی‌ترین مخالفتِ باقی‌مانده: اگر در آینده هر زنجیره‌ی باشگاه پنل و قابلیت‌هایِ اختصاصی بخواهد، مرزِ ماژولِ رزرو زیرِ فشار می‌رود و شاید جدا کردنش لازم شود.
- توصیه: مونولیتِ ماژولار با قانونِ سخت‌گیرانه که هر ماژول فقط جدول‌هایِ خودش را بخواند و بنویسد، به‌علاوه‌ی فهرستی از نشانه‌هایی که اگر دیده شدند، تصمیم دوباره باز شود.
برنده شدنِ یک پیشنهاد در آرنا یعنی زیرِ همین قیدها دفاع‌پذیرتر بود، نه این‌که بقیه همیشه غلط‌اند. اگر قیدها عوض شوند، مثلاً تیم بزرگ شود، همان نشست با قیدهایِ تازه ممکن است حکمِ دیگری بدهد.
از حکم تا سندِ تصمیم
بسیاری از تیم‌ها تصمیم‌هایِ معماری را در قالبی به نامِ ADR (سندِ کوتاهِ تصمیمِ معماری) ثبت می‌کنند: زمینه، تصمیم، گزینه‌هایی که کنار رفتند و پیامدها. حکمِ چندهوش تقریباً همین اجزا را دارد، پس تبدیلش ساده است:
- حکم را به Word ببر تا ویرایش‌پذیر باشد.
- موردهایِ توافق را به بخشِ «دلایلِ تصمیم» منتقل کن.
- گزینه‌هایِ حذف‌شده را با دلیلِ حذفشان در بخشِ «گزینه‌هایِ کنارگذاشته» بنویس.
- قوی‌ترین مخالفتِ باقی‌مانده را به‌عنوانِ «ریسکِ شناخته‌شده» ثبت کن؛ این همان چیزی است که شش ماه بعد باید دوباره نگاهش کنی.
- از «نقشه‌ی تصمیم» برایِ توضیحِ چراییِ حکم به هم‌تیمی‌ها استفاده کن و سند را در خودِ مخزن نگه دار.
یک نکته‌ی مهم دیگر برگشت‌پذیری است. تصمیم‌هایی که برگرداندنشان ارزان است، مثلِ انتخابِ یک کتابخانه داخلِ یک ماژول، ارزشِ نشستِ عمیق ندارند؛ با عمقِ «سریع» یا حتی بدونِ میزگرد جلو برو. عمق و هزینه را برایِ تصمیم‌هایی نگه دار که برگرداندنشان گران است: مدلِ داده، شکستنِ پایگاه‌داده، یا انتخابِ زبانِ اصلی.
کجا حرفِ مدل‌ها را با احتیاط بخوان
- عددهایِ کارایی: هر عددی که مدل درباره‌ی سرعت یا ظرفیتِ یک ابزار می‌دهد، حدس است. با آزمونِ بارِ خودت رویِ سخت‌افزارِ خودت بسنج.
- وضعیتِ روزِ ابزارها: قابلیت‌ها و نسخه‌ها زود عوض می‌شوند. «جست‌وجوی زنده قبل از شروع» اطلاعاتِ تازه را با منبع اضافه می‌کند و منابع در حکم می‌آیند؛ آن‌ها را باز کن و بخوان.
- تیمِ تو را نمی‌شناسند: مدل‌ها نمی‌دانند هم‌تیمی‌هایت در چه چیزی واقعاً قوی‌اند، مگر خودت بنویسی.
- توافق یعنی درستی نیست: همه‌ی مدل‌ها ممکن است یک توصیه‌ی رایج را تکرار کنند؛ برایِ همین اختلاف‌ها و مخالفتِ باقی‌مانده در حکم ثبت می‌شوند.
سبکِ استدلالِ مدل‌ها هم با هم فرق دارد و با هر نسخه عوض می‌شود. در مقایسه ChatGPT و Claude و Gemini روشی آمده که رویِ سؤالِ خودت امتحانشان کنی، و فهرستِ خانواده‌هایِ در دسترس را در صفحه‌ی مدل‌ها می‌بینی.
جمع‌بندی
انتخاب معماری نرم‌افزار با هوش مصنوعی یعنی سؤالِ کلی را به قیدهایِ مشخص تبدیل کنی، گزینه‌ها را در قالبی مثلِ مناظره یا آرنا در برابرِ هم بگذاری و حکم را به سندی تبدیل کنی که دلیل، ریسک و زمانِ بازنگری دارد. مدل‌ها جایِ قضاوتِ تو و شناختت از تیم را نمی‌گیرند، اما کمک می‌کنند معامله‌هایی را ببینی که در یک گفت‌وگویِ تک‌مدلی پنهان می‌ماند. برایِ کاربردهایِ دیگر کاربردهایِ چندهوش در تصمیم‌گیری را ببین.
وقتی معماری انتخاب شد و کد نوشته شد، بررسی کد با هوش مصنوعی قدمِ بعدی است. و اگر هنوز مطمئن نیستی خودِ محصول ارزشِ ساختن دارد، پیش از هر تصمیمِ فنی سراغِ بررسیِ ایده‌ی کسب‌وکار برو.