با ابزارهایی مثل Cursor و سایر AI Coderها، خیلیها وسوسه میشوند کل یک پروژه مایکروسرویسی را یکجا به AI بدهند و بگویند:
«این را برای من تبدیل کن به یک پروژه مونولیت که دقیقاً همان کارها را انجام بدهد.»
در ظاهر منطقی است. اگر AI میتواند کد بنویسد، چرا این کار را نکند؟
اما در عمل، این معمولاً تصمیم خوبی نیست.
خیلیها فکر میکنند مایکروسرویس یعنی چند پروژه جدا که اگر همه را یکی کنیم، مونولیت ساخته میشود.
اما واقعیت این نیست.
مایکروسرویس مثل یک شهر است:
هر سرویس مثل یک اداره مستقل
هر کدام قوانین خودش را دارد
با بقیه از راه پیام، API یا صف باهم حرف میزنند
بعضی کارها مرحلهای انجام میشود
بعضی اتفاقها پشت صحنه رخ میدهد
وقتی میگویی «همه را یکی کن»، انگار میگویی:
همه ادارههای یک شهر را در یک ساختمان بگذار، بدون اینکه هیچ چیزی خراب شود.
این فقط ادغام نیست؛ بازطراحی است.
مثال ساده:
فرض کنید در سیستم شما ثبت درخواست اینطور انجام میشود:
درخواست ثبت میشود
پرداخت چک میشود
پیامک ارسال میشود
فایل آزاد میشود
اگر مرحله ۳ خطا داد، مرحله ۲ برگردد
این منطق شاید در چند سرویس پخش شده باشد.
AI ممکن است این را اینطور تبدیل کند:
ثبت درخواست پرداخت ارسال پیامک اتمام
در ظاهر درست است.
ولی آن منطق “اگر خطا شد چه کن” حذف شده.
همین تفاوتهای کوچک در سیستم واقعی فاجعه میسازد.
در پروژههای بزرگ خیلی چیزها واضح نیست.
مثلاً:
این سرویس به Redis وابسته است
آن سرویس از RabbitMQ پیام میگیرد
یک Cron Job شبانه چیزی را اصلاح میکند
یک event مخفی سه سرویس دیگر را فعال میکند
خیلی از اینها در مستندات هم نیست؛ فقط در رفتار سیستم وجود دارد.
AI ممکن است این ارتباطهای پنهان را از دست بدهد.
نتیجه؟
سیستمی میگیرید که شبیه قبلی است، ولی دقیقاً مثل قبلی کار نمیکند.
بزرگترین اشتباه همین جمله است:
«دقیقاً همان کارکرد را بده.»
چون این کار برای انسان هم سخت است، چه برسد به AI.
مثلاً در سیستم اصلی شاید:
پرداخت دوبار انجام نشود
اگر شبکه قطع شد retry شود
دادهها eventually sync شوند
خطاها recover شوند
اینها فقط کد نیستند؛ رفتار سیستماند.
AI خیلی وقتها behavior را کامل بازسازی نمیکند.
و بازنویسی کامل از صفر، معمولاً پروژهها را میسوزاند.
سالها در مهندسی نرمافزار ثابت شده:
Big Bang Rewrite پرریسک است.
حالا اگر این را با AI انجام بدهید، فقط سریعتر وارد همان ریسک میشوید.
فرض کنید اینها را دارید:
سرویس کاربران
سرویس پرداخت
سرویس اپلای
سرویس نوتیفیکیشن
Redis
RabbitMQ
PostgreSQL
Auth
و به AI میگویید:
«همه را مونولیت کن.»
ممکن است خروجی تمیز هم باشد:
Controller دارد
Service Layer دارد
Database model دارد
ولی ممکن است اینها گم شده باشند:
منطق صفها
retryها
rollbackها
هماهنگی بین سرویسها
dependencyهای مخفی
یعنی ظاهر پروژه خوب است؛ باطن نه.
استفاده اشتباه بد است.
AI خیلی خوب است برای:
✅ تحلیل وابستگیها
✅ پیدا کردن couplingها
✅ کمک به refactor
✅ تبدیل سرویس به ماژول
✅ تولید تست
✅ کمک به migration مرحلهای
برای این نه:
❌ “کل سیستم را بگیر و یکجا بازنویسی کن.”
به جای این:
«کل پروژه را مونولیت کن»
بگویید:
Payment را جدا تحلیل کن
این سرویس را modular monolith کن
dependency map بساز
ریسکهای migration را پیدا کن
یعنی پروژه را تکهتکه جلو ببرید.
AI اینجا عالی است.
غلط:
این ۱۲ مایکروسرویس را بگیر و معادل مونولیت کامل بده.
درست:
اول ارتباط سرویسها را تحلیل کن.
بعد Payment Domain را به ماژول مونولیت تبدیل کن.
بعد تست تطابق بده.
زمین تا آسمان فرق دارد.
مایکروسرویس را نمیشود مثل چند فایل zip یکی کرد.
تبدیلش به مونولیت یک مسئله معماری است، نه صرفاً تولید کد.
ابزارهایی مثل Cursor فوقالعادهاند، اما برای کمک به این مسیر، نه انجام جادویی کل مسیر.
اگر کل پروژه را یکجا به AI بدهید و انتظار “همان سیستم دقیق” داشته باشید، معمولاً یا بخشی از منطق گم میشود، یا ریسک بزرگی وارد پروژه میکنید.
قاعده ساده:
برای بازطراحی معماری، از AI کمک بگیرید؛ کل معماری را به AI نسپارید.
