میکروسرویس یا مونولیت؟ بلوغ معماری در سال ۱۴۰۵

سیداحمدرضا محجوب · ۱۴۰۴/۱۱/۱۵ · 11 دقیقه

در خرداد ۱۴۰۵، بحث‌های داغ و تعصب‌آمیز پیرامون معماری نرم‌افزار به یک نقطه تعادل استراتژیک رسیده است. پس از یک دهه چرخش افراطی به سمت میکروسرویس‌های پیچیده و سپس بازگشت‌های پشیمان‌گونه به مونولیت، اکنون شاهد ظهور پارادا…

۱. آونگ معماری: یک دهه افراط و تفریط

برای فهم وضعیت امروز، باید مسیر آونگ را مرور کنیم. اوایل دهه ۲۰۱۰، موفقیت‌های نتفلیکس و آمازون، میکروسرویس (Microservices) را به نماد مهندسی مدرن تبدیل کرد و هزاران استارتاپ پنج‌نفره، معماری شرکت‌های…

۲. هزینه پنهان توزیع‌شدگی

هر فراخوانی که از مرز یک فرآیند عبور می‌کند، از دنیای قطعیت به دنیای احتمال وارد می‌شود. مغالطه‌های رایانش توزیع‌شده (Fallacies of Distributed Computing) — «شبکه قابل اعتماد است»، «تأخیر صفر است»، «پ…

۳. مونولیت ماژولار: مرز در کد، نه در شبکه

پاسخ سال ۱۴۰۵ به این دوگانه، مونولیت ماژولار (Modular Monolith) است: تمام کد در یک واحد استقرار، اما مرزهای دامنه‌ها (Domains) با همان سخت‌گیریِ میکروسرویس‌ها تعریف می‌شوند. هر ماژول، API داخلی صریح…

۴. قانون کانوی: معماری شما آینه سازمان شماست

هیچ بحث معماری بدون قانون کانوی (Conway's Law) کامل نیست: «سازمان‌ها سیستم‌هایی طراحی می‌کنند که آینه ساختار ارتباطی خودشان است.» میکروسرویس در اصل یک راه‌حل سازمانی است، نه فنی: وقتی ده‌ها تیم باید…