https://virgool.ir/feed/@m_17421119fa2026-11-10 15:28:44https://files.virgool.ir/upload/users/4885428/avatar/Sp7Q8g.pnghttps://virgool.ir/@m_17421119https://virgool.ir/@m_17421119/games-as-a-service-gaas-a-comparative-analysis-of-successful-and-failed-software-architectures-re29firwpgtdتحلیل معماری نرم‌افزار بازی‌های موفق سرویس‌محورچرا این مقاله را بخوانید؟اگر معمار نرم‌افزار، توسعه‌دهنده بازی یا فعال حوزه گیم هستید، این مقاله به شما نشان می‌دهد که چرا بازی Fortnite با ۱۱۰ میلیون بازیکن ماهانه، موفق شد و Anthem با ۵۹ امتیاز متاکریتیک، سرورهایش را در ژانویه ۲۰۲۶ خاموش کرد!۷ الگوی معماری که در این مقاله استخراج شده، نقشه راهی عملی برای ساخت بازی‌های سرویس‌محور است.چکیدههدف از نگارش این پژوهش، واکاوی نقش معماری نرم‌افزار در موفقیت بازی‌های سرویس‌محور است. بدین منظور، نوزده منبع معتبر شامل مقالات علمی، گزارش‌های صنعتی، مستندات فنی و مصاحبه‌های تخصصی با بهره‌گیری از روش مرور ساختاریافته ادبیات، مورد تحلیل و بررسی قرار گرفته‌اند.یافته‌های حاصل نشان می‌دهند که هفت الگوی معماری کلیدی در بازی‌های موفق سرویس‌محور اعم از : معماری میکروسرویس، محاسبات لبه، معماری سرور-معتبر، انتقال میزبان، تحویل هوشمند، معماری رویدادمحور و محاسبات بدون سرور قابل شناسایی می‌باشند. از میان این هفت الگو، پنج الگوی نخست، نقشی حیاتی در موفقیت بازی ایفا می‌کنند.تحلیل تطبیقی بازی فورتنایت (موفق) و آنتم (ناموفق) نشان می‌دهد که فورتنایت در تمامی هفت الگوی معماری به موفقیت دست یافته است و با در اختیار داشتن حدود یکصد و ده میلیون بازیکن ماهانه و حدود پنج و هشت دهم میلیارد دلار درآمد سالانه، به یکی از موفق‌ترین بازی‌های تاریخ بدل گشته است. در مقابل، آنتم با کسب نمره پنجاه و نه از صد در وب‌سایت متاکریتیک و خاموشی سرورهای خود در دوازدهم ژانویه سال دو هزار و بیست و شش، به یکی از بزرگ‌ترین شکست‌های صنعت بازی تبدیل شده است.نتیجه‌گیری نهایی آن است که معماری مناسب، شرطی لازم برای موفقیت به شمار می‌رود، اما به تنهایی کافی نمی‌باشد. موفقیت در بازی‌های سرویس‌محور، حاصل آمیزه‌ای از معماری درست، مدیریت صحیح، تیم متخصص، مدل درآمدی مناسب و مهم‌تر از همه، احترام به بازیکنان است.کلمات کلیدی: Games-as-a-Service، معماری نرم‌افزار، فورتنایت، آنتم، بازی‌های ابری، میکروسرویس، محاسبات لبه۱. مقدمهاکوسیستم بازی‌های ویدئویی در روزگار کنونی، از اقتصاد بسیاری از کشورها فراتر رفته است. بر اساس گزارش‌های صنعتی، ارزش این اکوسیستم در سال دو هزار و بیست و چهار، از دویست میلیارد دلار عبور نموده و پیش‌بینی می‌شود که تا سال دو هزار و سی، به بیش از سیصد میلیارد دلار دست یابد. در قلب این تغییرات، مدل Games-as-a-Service جای گرفته است؛ مدلی که در آن بازی‌ها به‌جای آنکه محصولی یک‌بارفروش باشند، به‌عنوان سرویسی پیوسته با به‌روزرسانی‌های منظم و محتوای تازه ارائه می‌گردند.در مدل سنتی، پس از انتشار بازی، کار توسعه، پایان‌یافته تلقی می‌شد. اما در مدل سرویس‌محور، انتشار بازی نقطه‌آغاز فصلی جدید است بازی‌هایی چونFortnite، Genshin Impact و Call of Duty: Warzone، با ارائه محتوای نو، رویدادهای زنده و تعامل مستمر با بازیکنان، توانسته‌اند سال‌ها در صدر جدول محبوب‌ترین بازی‌ها باقی بمانند. اما در سوی مقابل، بازی‌هایی مانندAnthem، Concord ، The Day Before، با وجود وعده‌های بزرگ، در مدت زمانی کوتاه با شکست مواجه گشتند و به عمر خود پایان دادند.۲. روش‌شناسی پژوهش۲-۱. رویکرد کلی پژوهشبرای انجام این پژوهش، از روش مرور ساختاریافته ادبیات با رویکرد تحلیل تطبیقی بهره گرفته شده است. این روش برای پژوهش‌هایی مناسب است که هدف از آنها شناسایی الگوهای تکراری از میان منابع پراکنده و انجام تحلیل تطبیقی عمیق می‌باشد [۱].دلیل انتخاب این روش، تنوع منابع، ماهیت میان‌رشته‌ای موضوع و هدف پژوهش بوده است. منابع این پژوهش شامل مقالات علمی، گزارش‌های صنعتی، مستندات فنی و مصاحبه‌های تخصصی هستند که هر یک نیازمند رویکرد تحلیلی متفاوتی می‌باشند.۲-۲. پرسش پژوهشپژوهش حاضر در پی پاسخ به این پرسش اصلی است:آیا معماری نرم‌افزار به تنهایی می‌تواند موفقیت یک بازی سرویس‌محور (GaaS) را تضمین نماید؟برای پاسخ به این پرسش، سه زیرپرسش نیز مطرح شده‌اند:۱. چه مدل‌ها و الگوهای معماری در بازی‌های GaaS وجود دارند؟۲. چه عواملی در موفقیت یا شکست معماری یک بازی GaaS نقش ایفا می‌کنند؟۳. چه درس‌هایی از مقایسه تطبیقی فورتنایت (موفق) و آنتم (ناموفق) برای توسعه‌دهندگان GaaS قابل استخراج می‌باشند؟۲-۳. استراتژی انتخاب منابعبرای انتخاب منابع، از رویکردی ترکیبی بهره گرفته شده است. ابتدا مقاله بنیادین کای و همکاران [۱] به‌عنوان نخستین مقاله جامع در حوزه معماری GaaS شناسایی گردید و سپس با بررسی ارجاعات به این مقاله، منابع بعدی با روش برفکی یافت شدند. در مرحله پسین، با جستجوی کلیدواژه‌های تخصصی در پایگاه‌های دادهداده IEEE Xplore، ACM Digital Library و Google Scholar، منابع بیشتری شناسایی شدند.از میان سی و دو منبع اولیه، نوزده منبع بر اساس معیارهای مشخصی گزینش شدند. این معیارها شامل مرتبط بودن با معماری فنی بازی‌های سرویس‌محور، دارا بودن داده‌های عددی یا تحلیل ساختاریافته، داشتن مطالعه موردی از بازی‌های واقعی، و معتبر بودن منبع می‌باشند. بازه زمانی منابع از سال دو هزار و چهارده تا دو هزار و بیست و شش را در بر می‌گیرد. منابع صرفاً مدیریتی یا بازاریابی فاقد داده‌های فنی، منابع تکراری، و منابع مرتبط با بازی‌های سنتی از مجموعه حذف شده‌اند.۲-۴. فرآیند تحلیلپس از انتخاب منابع نهایی، فرآیند تحلیل در چهار مرحله انجام پذیرفت:مرحله اول: مطالعه اولیه و خلاصه‌نویسی - هر منبع یک‌بار کامل خوانده شد و خلاصه‌ای از آن تهیه گردید.مرحله دوم: کدگذاری موضوعی - مفاهیم کلیدی هر منبع استخراج و برچسب‌گذاری شدند. نمونه کدها: "مدل معماری"، "زیرساخت ابری"، "الگوی درآمدزایی"، "عامل شکست" است.مرحله سوم: دسته‌بندی و ترکیب - کدهای مشابه در چهار دسته اصلی ترکیب شدند: مدل‌های معماری [۱، ۲، ۳]، زیرساخت و کاهش تأخیر [۴، ۷، ۱۱]، مطالعه موردی موفق [۱۰، ۱۱، ۹]، و مطالعه موردی ناموفق است [۱۴، ۱۵، ۱۶].مرحله چهارم: تحلیل تطبیقی - مقایسه یافته‌های منابع مختلف برای شناسایی الگوهای تکراری انجام شد.برای افزایش اعتبار یافته‌ها، از مثلث‌سازی داده‌ها بهره گرفته شده است؛ به این معنا که از منابع متنوع (مقالات علمی، گزارش‌های صنعتی، مصاحبه‌های تخصصی و مستندات فنی) برای تأیید یافته‌ها از چند منظر استفاده گردیده است.۳. مبانی نظری و مرور منابع۳-۱. سه مدل معماری GaaSمقاله کای و همکاران [۱] یکی از مهم‌ترین و بنیادی‌ترین منابع در حوزه GaaS به شمار می‌رود که به‌عنوان نخستین کار جامع در زمینه طبقه‌بندی معماری‌های GaaS شناخته می‌شود. نویسندگان با نگاهی سیستماتیک، سه مدل معماری متفاوت را معرفی می‌کنند.مدل نخست: RR-GaaSدر این مدل، همه ماژول‌های بازی شامل منطق، رندرینگ و رمزگذاری در ابر اجرا می‌شوند و تنها ویدیوی نهایی به دستگاه کاربر ارسال می‌گردد. این مدل به پهنای باند بالا و تأخیر کم نیاز دارد و تأخیر قابل تحمل آن کمتر از 120میلی‌ثانیه است. مزیت اصلی این مدل آن است که کاربر به سخت‌افزار قدرتمندی نیاز ندارد و بازی در برابر دزدی مصون می‌ماند. اما پهنای باند بسیار بالا، حساسیت به تأخیر و هزینه بالای سرور از معایب آن به شمار می‌روند. نمونه‌های صنعتی این مدل شامل OnLive، Gaikai و G-Cluster می‌باشند.RR-GaaSمدل دوم: LR-GaaSدر این مدل، منطق بازی در سرور ابری اجرا می‌شود، اما رندرینگ و نمایش ویدیو در دستگاه کاربر انجام می‌گیرد. این مدل به پردازنده گرافیکی مناسب در دستگاه کاربر نیاز دارد. مزایای آن کاهش بار شبکه، تأخیر کمتر، کیفیت بالاتر و هزینه کمتر برای ارائه‌دهنده است. اما نیاز به سخت‌افزار گرافیکی، طراحی مجموعه دستورات، وابستگی به سیستم‌عامل و امنیت کمتر از معایب آن به شمار می‌روند.LR-GaaSمدل سوم: CRA-GaaSدر این مدل، برنامه بازی به مؤلفه‌های مستقل تقسیم می‌شود و هر مؤلفه می‌تواند به‌صورت پویا میان ابر و دستگاه کاربر جابه‌جا گردد. این مدل انعطاف‌پذیری بالا، بهره‌وری بهینه از منابع و تعمیم‌پذیری دارد و برای بازی‌های موبایل مناسب می‌نماید. اما پیچیدگی بالای پیاده‌سازی، هماهنگی مؤلفه‌ها و همگام‌سازی داده از معایب آن هستند.نکته شایان توجه آن است که نوع بازی تأثیری مستقیم بر انتخاب معماری مناسب دارد. بازی‌های تیراندازی اول شخص و استراتژی لحظه‌ای به دلیل نیاز به تأخیر کم، معماری LR-GaaS یا CRA-GaaS را ترجیح می‌دهند، در حالی که بازی‌های نقش‌آفرینی نوبتی و مدیریتی به دلیل تحمل تأخیر بالاتر، می‌توانند از RR-GaaS بهره ببرند.۳-۲. معماری هفت‌لایه زیرساختمقاله امینی و همکاران [۲] که در یکی از کنفرانس‌های داخلی ایران منتشر گردیده، در پی طراحی و پیاده‌سازی زیرساختی جامع و بزرگ‌مقیاس برای ارائه خدمات توسعه بازی است. نویسندگان معماری هفت‌لایه‌ای پیشنهاد می‌دهند که از کلاینت تا حاکمیت و نظارت را پوشش می‌دهد.معماری هفت‌لایه زیرساختلایه نخست، کلاینت است که شامل دستگاه‌های مختلف مانند کامپیوتر شخصی، موبایل، کنسول و تبلت می‌شود. لایه دوم، شبکه است که شامل CDN، سرورهای لبه، متعادل‌کننده‌های بار و دروازه‌ها می‌گردد. لایه سوم، یکپارچه‌سازی سرویس‌هاست که شامل Enterprise Service Bus و Message Broker می‌شود. لایه چهارم، چرخه حیات توسعه است که مدیریت API، توسعه و DevOps را در بر می‌گیرد. لایه پنجم، سرویس‌های پایه مانند هوش مصنوعی، رسانه، واقعیت مجازی و واقعیت افزوده هستند. لایه ششم، داده است که شامل پایگاه‌های داده SQL و NoSQL و ذخیره‌سازی فایل می‌شود. لایه هفتم، حاکمیت و نظارت است که شامل سیاست‌های حاکمیتی و پایش سرویس‌ها می‌گردد.مقالات [۱] و [۲] دو رویکرد مکمل اما متفاوت به معماری GaaS ارائه می‌دهند. مقاله [۱] از منظر مدل‌های اجرایی به مسئله می‌نگرد و سه معماری RR-GaaS، LR-GaaS و CRA-GaaS را بر اساس محل اجرای مؤلفه‌های بازی (ابر در برابر کلاینت) دسته‌بندی می‌کند. در مقابل، [۲] رویکردی سیستمی‌تر دارد و زیرساختی جامع هفت‌لایه را از کلاینت تا حاکمیت و نظارت ارائه می‌دهد.به عبارت دیگر،[۱] به این می‌پردازد که "چه چیزی" در کجا اجرا شود ، در حالی که [۲] به این می‌پردازد که "چگونه" زیرساخت لازم برای پشتیبانی از بازی‌های سرویس‌محور باید باشد. این دو مقاله مکمل یکدیگرند۳-۳. مقایسه معماری یکپارچه و توزیع‌شدهمقاله [۳] به‌صورت عملی به مقایسه دو رویکرد معماری در بازی‌های ابری می‌پردازد. در معماری یکپارچه، همه سیستم‌های بازی مانند رندرینگ، فیزیک و منطق در یک نمونه اجرا می‌شوند. در معماری توزیع‌شده، سیستم‌های بازی از هم جدا شده و به‌صورت سرویس‌های مستقل اجرا می‌گردند.نتایج آزمایش‌های این مقاله نشان می‌دهد که در سناریوهای با تعداد اشیاء بالا، معماری توزیع‌شده عملکردی بهتر دارد. برای نمونه، در سناریوی دو هزار شیء، معماری توزیع‌شده حدود 5.26 میلی‌ثانیه سریع‌تر از معماری یکپارچه عمل نموده است. همچنین، یک سرور بهینه‌شده برای محاسبات، تقریباً 2.3 برابر سریع‌تر از یک سرور تخصصی گرافیکی، محاسبات فیزیک را انجام می‌دهد. این یافته‌ها نشان می‌دهند که برای بازی‌های سرویس‌محور با تعداد بالای موجودیت‌ها، معماری توزیع‌شده انتخابی بهتر است.مقایسه معماری یکپارچه و توزیع‌شده۴. الگوهای معماری بازی‌های سرویس‌محوربر اساس مرور نظام‌مند بیست منبع و تحلیل تطبیقی فورتنایت و آنتم، هفت الگوی معماری تکراری در بازی‌های موفق سرویس‌محور شناسایی گردیده است. در ادامه، هر یک از این الگوها با جزییات بیشتری بررسی می‌شوند.۴-۱. معماری میکروسرویسمعماری میکروسرویس به معنای جداسازی سرویس‌های بازی به‌عنوان واحدهایی مستقل است که هر یک می‌توانند به‌طور جداگانه توسعه، استقرار و مقیاس‌دهی شوند. بر اساس مقاله [۳]، معماری توزیع‌شده در سناریوهای سنگین عملکردی بهتر از معماری یکپارچه دارد. در آزمایش‌های این مقاله، معماری توزیع‌شده در سناریوی دو هزار شیء، پنج و بیست و شش میلی‌ثانیه سریع‌تر از معماری یکپارچه بود.مطابق با مقاله [۲]، یک زیرساخت GaaS موفق باید از لایه یکپارچه‌سازی سرویس‌ها پشتیبانی نماید. نویسندگان تأکید می‌کنند که موتورهای بازی یکپارچه مانند فراست‌بایت، نمی‌توانند از مزایای معماری سرویس‌گرا بهره‌مند شوند.فورتنایت با معماری میکروسرویس به موفقیت دست یافت، در حالی که آنتم با معماری یکپارچه فراست‌بایت شکست خورد. این تفاوت در رویکرد، یکی از مهم‌ترین دلایل موفقیت فورتنایت و شکست آنتم به شمار می‌رود.۴-۲. محاسبات لبهمحاسبات لبه به معنای قرار دادن سرورهای بازی در نزدیکی کاربران برای کاهش تأخیر است. مقاله [۷] نشان می‌دهد که محاسبات لبه می‌تواند تأخیر را تا 25 میلی‌ثانیه نسبت به محاسبات ابری کاهش دهد. نتایج حاکی از آن است که حداقل تأخیر ممکن در بازی‌های لبه حدود 46 میلی‌ثانیه و در بازی‌های ابری حدود 71 میلی‌ثانیه می‌باشد.گزارش [۱۱] نشان می‌دهد که فورتنایت با استفاده از بیست و شش منطقه در دسترس در AWS، سرورهای خود را در نزدیکی کاربران در سراسر جهان مستقر نموده است. این در حالی است که آنتم با سرورهای متمرکز EA، تأخیر بالایی داشت.نیم‌نگاهی به یک توزیع سرور محاسبات لبه۴-۳. معماری سرور-معتبرمعماری سرور-معتبر به معنای اعتبارسنجی همه اقدامات در سمت سرور است. در بازی‌های چندنفره، این الگو برای جلوگیری از تقلب حیاتی می‌باشد. اگر اقدامات بازیکنان تنها در دستگاه خودشان اعتبارسنجی شود، بازیکنان می‌توانند با دستکاری کد، امتیاز بگیرند یا به دیگران زیان برسانند.مطابق با وایت‌پیپر متاپلی [۱۰]، فورتنایت از معماری سرور-معتبر استفاده می‌کند و همه اقدامات بازیکنان در سرورهای AWS تأیید می‌شود. به نقل از تیمو هیلای، مدیر محصول متاپلی: "اگر چیزی در بازی شما ارزش خرید داشته باشد، کسی سعی می‌کند از طریق تقلب به آن دست یابد، تنها دفاعی که واقعاً کار می‌کند، معماری سرور-معتبر است." در مقابل، آنتم پیاده‌سازی ضعیفی از این الگو داشت که به مشکلات متعددی در بازی انجامید.معماری سرور-معتبر۴-۴. انتقال میزبانانتقال میزبان به معنای قابلیت انتقال میزبان به سرور دیگر در صورت قطعی است. این الگو برای بازی‌های چندنفره حیاتی می‌نماید تا وقتی یک سرور دچار مشکل می‌شود، بازی متوقف نگردد.مارک دارا، تهیه‌کننده اجرایی سابق  BioWare، در مصاحبه با GameSpot در 2025 به صراحت اعتراف نموده است: "ما نمی‌دانستیم چگونه انتقال میزبان را انجام دهیم، و صادقانه بگویم توانایی مالی آن را نیز نداشتیم." او به Destiny اشاره می‌کند که این فناوری را به‌درستی پیاده‌سازی نموده است. این در حالی است که  Fortnite با استفاده از سرورهای اختصاصی AWS از این قابلیت پشتیبانی کامل می‌کند.انتقال میزبان۴-۵. تحویل هوشمندتحویل هوشمند به معنای مدیریت حجم بازی با قابلیت نصب انتخابی بخش‌هاست. بازی‌های امروزی بسیار بزرگ شده‌اند و دانلود و نصب کامل آنها زمان‌بر است. با استفاده از این الگو، بازیکن می‌تواند تنها بخش‌هایی از بازی را که نیاز دارد نصب نماید.مستندات Microsoft GDK [۱۹] نشان می‌دهد که فورتنایت از این قابلیت بهره می‌برد و حجم بازی را مدیریت نموده است، در حالی که حجم آنتم بیش از 100 گیگابایت بود و این موضوع برای بسیاری از بازیکنان مانعی بزرگ محسوبمی‌شد.تحویل هوشمند۴-۶. معماری رویدادمحورمعماری رویدادمحور به معنای واکنش به رویدادها برای به‌روزرسانی بی‌درنگ است. در این الگو، سیستم‌ها به‌جای درخواست مداوم داده از یکدیگر، به رویدادها واکنش نشان می‌دهند. این رویکرد برای بازی‌های سرویس‌محور که نیاز به به‌روزرسانی‌های مکرر دارند، بسیار مناسب می‌نماید.مطابق با وایت‌پیپر متاپلی [۱۰]، فورتنایت از معماری رویدادمحور برای به‌روزرسانی‌های هفتگی بدون توقف استفاده می‌کند، در حالی که آنتم به‌روزرسانی‌های ماهانه با توقف داشت. این تفاوت در رویکرد، یکی از دلایل اصلی ماندگاری فورتنایت در بازار است.۴-۷. محاسبات بدون سرورمحاسبات بدون سرور به معنای اجرای کد بدون مدیریت سرور است. در این الگو، توسعه‌دهنده کد را اجرا می‌کند و زیرساخت ابری به‌طور خودکار مدیریت می‌شود. این رویکرد برای بک‌اند بازی‌ها بسیار مناسب است، زیرا توسعه‌دهنده نیازی به نگرانی درباره مدیریت سرورها ندارد.گزارش AWS Lens [۱۱] نشان می‌دهد که فورتنایت از AWS Lambda برای بک‌اند خود استفاده می‌کند، در حالی که آنتم مدیریت دستی سرورها را داشت. این تفاوت در رویکرد، هزینه و پیچیدگی نگهداری آنتم را به‌شدت افزایش داده بود.۴-۸. جمع‌بندی الگوهابر اساس تحلیل‌های انجام‌شده، پنج الگوی نخست یعنی معماری میکروسرویس، محاسبات لبه، معماری سرور-معتبر، انتقال میزبان و معماری رویدادمحور نقشی حیاتی در موفقیت بازی‌های سرویس‌محور ایفا می‌کنند. دو الگوی دیگر یعنی تحویل هوشمند و محاسبات بدون سرور نیز مهم می‌نمایند اما نه به اندازه پنج الگوی نخست.نتیجه کلیدی: شکست آنتم یک تصادف نبوده است. این بازی در تمامی هفت الگوی معماری موفق شکست خورده یا ضعیف عمل نموده است. در مقابل، فورتنایت در تمامی هفت الگو به موفقیت دست یافته است.۵. تحلیل تطبیقی Fortnite و Anthem۵-۱. تحلیل Fortniteفورتنایت توسط اپیک گیمز در سال دو هزار و هفده منتشر گردید. با اضافه شدن حالت بتل رویال و انتشار به‌روزرسانی‌های هفتگی، رویدادهای زنده و همکاری با برندهای معروف، این بازی موفق شد پس از هفت سال همچنان در صدر باقی بماند.معماری این بازی ترکیبی از مدل‌های LR-GaaS و CRA-GaaS است. این بازی از معماری میکروسرویس با AWS Lambda و ECS بهره می‌برد و زیرساخت ابری آن در بیست و شش منطقه AWS مستقر گردیده است. برای کاهش تأخیر، از AWS Global Accelerator استفاده می‌کند و موتور بازی آن آنریل انجین است که به‌صورت ماژولار طراحی شده است.مدل درآمدیFortnite، رایگان با خریدهای درون‌برنامه‌ای است که شامل بتل‌پس و لوازم آرایشی شخصی‌سازی‌شده می‌شود. مطابق با مقاله [۹]، تجربه «غرق شدن در بازی» و انگیزه «فرار از واقعیت» قوی‌ترین پیش‌بینی‌کننده‌های هزینه در بازی‌های رایگان هستند. فورتنایت با طراحی گیم‌پلی سریع و روان، بارگذاری سریع و رویدادهای مداوم، این دو عامل را به‌خوبی تأمین نموده است.همچنین، گزارش [۱۷] نشان می‌دهد که شخصی‌سازی شخصیت‌ها با 39 درصد، مهم‌ترین عامل جذب بازیکنان و هزینه در بازی‌های GaaS است. فورتنایت با ارائه هزاران اسکین، ایموت و آیتم شخصی‌سازی‌شده، این نیاز را به‌خوبی برآورده ساخته است.فورتنایت حدود یکصد و ده میلیون بازیکن ماهانه و حدود پنج و هشت دهم میلیارد دلار درآمد سالانه دارد و در تمام هفت الگوی معماری به موفقیت دست یافته است.Fortnite۵-۲. تحلیل Anthemآنتم توسط BioWare در سال 2019 با شش سال توسعه و هزینه بیش از یکصد میلیون دلار منتشر شد. Casey Hudson، مدیر پروژه، بازی را با چشم‌انداز "BioWare جدید" و "یک بازی BioWare با فروش فیفا" به EA فروخت، اما در حین توسعه استعفا داد.به نقل از مارک دارا: "حتی مشخص نیست که کیسی خودش می‌دانست این به چه معناست. اما حتی اگر هم می‌دانست، او حضور ندارد تا آن عبارت را شفاف‌سازی نماید."بازی در نهایت با نمره پنجاه و نه از صد در متاکریتیک منتشر گردید. به نقل از مقاله دوبوا [۴]: "محتوای جدید هرگز نتوانست چیزی را که به‌طور گسترده به‌عنوان یک تجربه ضعیف نقد شده بود، نجات دهد." سرورهای آنتم در دوازدهم ژانویه سال دو هزار و بیست و شش خاموش شدند.معماری فنیAnthem تلاشی ناموفق برای RR-GaaS بود. موتور بازی آن فراست‌بایت بود که موتوری یکپارچه محسوب می‌شود و برای بازی‌های چندنفره بزرگ طراحی نشده است. ساختار سرویس‌های آن شامل سه لایه ناهماهنگ یعنی Blaze، BIGS و Frostbite بود. زیرساخت آن در دیتاسنترهای متمرکز EA قرار داشت و انتقال میزبان در آن پیاده‌سازی نشده بود. حجم بازی نیز بیش از یکصد گیگابایت بود.گزارش آرس تکنیکا [۱۶] نشان می‌دهد که معماری آنتم به‌شدت وابسته به داده‌های سرور است: "به‌دلیل نحوه طراحی فراست‌بایت، تمام گیم‌پلی در یک بازی فراست‌بایت در بستر 'سرور' اجرا می‌شود."آنتم در تمام هفت الگوی معماری شکست خورده یا ضعیف عمل نموده است و با نمره پنجاه و نه از صد، یکی از بزرگ‌ترین شکست‌های صنعت بازی محسوب می‌شود.Anthem۵-۳. جدول مقایسه تطبیقیجدول مقایسه تطبیقی دو بازی موفق و ناموفق به شرح زیر است:جدول مقایسه تطبیقی Anthem و Fortnite۵-۴. تحلیل علت‌شناسی شکست آنتمشکست آنتم را می‌توان در سه سطح تحلیل نمود:سطح نخست: چشم‌انداز و مدیریتچشم‌انداز آنتم مبهم بود. کیسی هادسون از «آینده داستان‌سرایی» سخن می‌گفت، اما حتی خودش نیز نمی‌دانست این به چه معناست. او در حین توسعه استعفا داد و هدف غیرواقع‌بینانه "یک بازی بیوویر با فروش فیفا" هرگز محقق نشد.سطح دوم: معماری و فناوریموتور فراست‌بایت برای بازی‌های تیراندازی اول شخص طراحی شده بود، نه برای بازی‌های چندنفره بزرگ. معماری یکپارچه آن نمی‌توانست از مزایای سرویس‌گرایی بهره‌مند شود. سه سرویس ناهماهنگ Blaze، BIGS و Frostbite به‌درستی با یکدیگر ارتباط برقرار نمی‌کردند و انتقال میزبان در آن پیاده‌سازی نشده بود.سطح سوم: منابع انسانی و مالیهفت عضو کلیدی تیم در طول توسعه خارج شدند. فشار کاری بالا در شش سال توسعه، به فرسودگی نیروی انسانی انجامید. پس از شکست بازی، منابع کافی برای تعمیر آن وجود نداشت و هزینه بیش از یکصد میلیون دلاری، بدون بازگشت سرمایه باقی ماند.تحلیل شکست آنتم در سه سطح۵-۵. پاسخ به پرسش اصلی پژوهشبرای موفقیت در بازی‌های سرویس‌محور، سه لایه باید به‌درستی طراحی شوند:لایه نخست: معماری نرم‌افزار-شرط لازماین لایه شامل هفت الگویی است که در بخش پیشین بررسی شدند. معماری نیکو شرطی لازم برای موفقیت است. فورتنایت در تمام هفت الگو موفق بود و آنتم در هیچ‌یک موفق نبوده‌است.لایه دوم: عوامل انسانی و مدیریتی - شرط کافیمعماری نیکو به تنهایی کافی نیست. چشم‌انداز مشخص و پایدار، تیم متخصص و با تجربه، مدیریت منابع و بودجه، و مهم‌تر از همه، توجه به بازیکنان از عوامل کلیدی موفقیت هستند.لایه سوم: مدل کسب‌وکار و درآمدزایی - شرط رشدمدل درآمدی باید با بازی و بازیکنان هماهنگ باشد. فورتنایت با مدل رایگان و بتل‌پس به موفقیت دست یافت، در حالی که آنتم با مدل پولی و فروشگاه دیرهنگام، نتوانست بازیکنان را جذب نماید.معماری پیشنهادی در سه سطح برای بازی های موفق سرویس محو۶. نتیجه‌گیری۶-۱. خلاصه یافته‌های کلیدیبر اساس تحلیل بیست منبع معتبر و بررسی تطبیقی فورتنایت و آنتم، یافته‌های زیر به دست آمده است:۱. هفت الگوی معماری در بازی‌های موفق سرویس‌محور شناسایی شدند: معماری میکروسرویس، محاسبات لبه، معماری سرور-معتبر، انتقال میزبان، تحویل هوشمند، معماری رویدادمحور و محاسبات بدون سرور است.۲. از میان این هفت الگو، پنج الگوی نخست (میکروسرویس، محاسبات لبه، سرور-معتبر، انتقال میزبان، رویدادمحور) نقشی حیاتی در موفقیت بازی ایفا می‌کنند.۳. معماری یکپارچه با بازی‌های سرویس‌محور ناسازگار است. آزمایش‌های اولیویرا [۳] نشان داد که معماری توزیع‌شده حدود پنج میلی‌ثانیه سریع‌تر از معماری یکپارچه عمل می‌کند.۴. محاسبات لبه تأخیر را تا بیست و پنج میلی‌ثانیه کاهش می‌دهد [۷].۵. انتقال میزبان یک ضرورت فنی برای بازی‌های چندنفره است [۱۵].۶. تجربه غرق شدن در بازی قوی‌ترین پیش‌بینی‌کننده هزینه بازیکنان است (نسبت شانس ۱.۹۳) [۹].۷. شخصی‌سازی، مهم‌ترین عامل جذب بازیکنان است (۳۹٪) [۱۷].۸. مدیریت ضعیف می‌تواند معماری نیکو را نیز شکست دهد [۴].۹. فورتنایت در تمام هفت الگوی معماری موفق بوده و آنتم در هیچ‌یک موفق نبوده‌است.۱۰. موفقیت در GaaS نتیجه ترکیبی از معماری درست، مدیریت صحیح، تیم متخصص، مدل درآمدی مناسب و احترام به بازیکنان است.۶-۲. توصیه‌های عملی برای توسعه‌دهندگانبر اساس یافته‌های این پژوهش، ده توصیه عملی به توسعه‌دهندگان بازی‌های سرویس‌محور ارائه می‌شود:از معماری توزیع‌شده (میکروسرویس) استفاده کنیدسرورها را در لبه شبکه قرار دهید.انتقال میزبان را از روز اول پیاده‌سازی کنید.معماری سرور-معتبر را طراحی کنید.متاگیم را همزمان با هسته بازی طراحی کنید.به‌روزرسانی‌های مداوم با معماری رویدادمحور داشته باشید.چشم‌انداز مشخص و پایدار داشته باشید.به بازیکنان گوش دهید و بر اساس بازخورد عمل کنید.از Pay-to-Win اجتناب کنید.حجم بازی را با تحویل هوشمند مدیریت کنید.۶-۳. محدودیت‌های پژوهشاین پژوهش دارای محدودیت‌هایی است:تحلیل بر اساس داده‌های ثانویه انجام شده است و امکان بررسی مستقیم کد بازی‌ها وجود نداشت.ممکن است یافته‌ها به سایر بازی‌های GaaS با ژانرهای متفاوت قابل‌تعمیم نباشند.برخی منابع صنعتی ممکن است دارای سوگیری تبلیغاتی باشند.الگوهای معماری ممکن است در ژانرهای مختلف عملکردی متفاوت داشته باشند.صنعت بازی به‌سرعت در حال تغییر است و یافته‌ها ممکن است در آینده نیاز به بازبینی داشته باشند.۶-۵. سخن پایانیمعماری نرم‌افزار، قلب یک بازی سرویس‌محور است؛ اما این قلب بدون اکسیژن مدیریت صحیح، تیم متخصص، مدل درآمدی مناسب و مهم‌تر از همه، احترام به بازیکنان، هرگز نخواهد تپید.فورتنایت و آنتم هر دو با وعده‌های بزرگ آغاز کردند، اما مسیرهایی متفاوت را پیمودند. فورتنایت با انتخاب‌های درست معماری و مدیریتی، به یکی از پرفروش‌ترین بازی‌های تاریخ با حدود یکصد و ده میلیون بازیکن ماهانه و حدود پنج و هشت دهم میلیارد دلار درآمد سالانه بدل شد. آنتم با انتخاب‌های اشتباه، به یکی از بزرگ‌ترین شکست‌های صنعت بازی با نمره پنجاه و نه از صد در متاکریتیک تبدیل شد و سرورهای آن در دوازدهم ژانویه سال دو هزار و بیست و شش خاموش گردیدند.از روز نخست به معماری بیندیشید، اما فراموش نکنید که معماری به تنهایی کافی نیست. موفقیت در بازی‌های سرویس‌محور نتیجه ترکیبی از معماری درست، مدیریت صحیح، تیم متخصص، مدل درآمدی مناسب و مهم‌تر از همه، احترام به بازیکنان است.۷. واژه‌نامهGaaS مدل ارائه بازی به‌عنوان سرویس مداومRR-GaaS رندرینگ از راه دور - رندرینگ ویدیو در ابرLR-GaaS رندرینگ محلی - رندرینگ در دستگاه کاربرCRA-GaaS تخصیص پویای مؤلفه‌ها - جابجایی پویا بین ابر و کلاینتMicroservices معماری مبتنی بر سرویس‌های مستقلEdge Computing محاسبات در لبه شبکه، نزدیک به کاربرانServer-Authoritative اعتبارسنجی همه اقدامات در سمت سرورHost Migration انتقال میزبان به سرور دیگر در صورت قطعیIntelligent Delivery مدیریت حجم بازی با نصب انتخابی بخش‌هاEvent-Driven Architecture معماری مبتنی بر رویدادهاServerless Computing اجرای کد بدون مدیریت سرورBattle Pass سیستم پاداش‌های فصلی در بازی‌های رایگانF2P بازی رایگان با خریدهای درون‌برنامه‌ایMeta-Game لایه فرابازی شامل پیشرفت، فروشگاه، بتل‌پسLiveOps عملیات زنده شامل رویدادها و به‌روزرسانی‌هاMonolithic معماری یکپارچهFrostbite موتور بازی یکپارچه EAUnreal Engine موتور بازی ماژولار Epic GamesAWS Amazon Web Services - زیرساخت ابریFlow حالت غرق شدن کامل در بازی۸. فهرست منابع[1] W. Cai, M. Chen, and V. C. M. Leung, "Toward Gaming as a Service," IEEE Internet Computing, pp. 12-18, 2014.[2] P. Amini, S. A. Z. Motlagh, and M. Nezhadpour, "A Large-Scale Infrastructure for Serious Games Services," in 2nd Digital Games Research Conference (DGRC), 2018.[3] S. S. de Oliveira, C. H. R. Souza, J. C. Silva, and S. T. Carvalho, "Towards Scalable Cloud Gaming Systems: Decoupling Physics from the Game Engine," in 22nd Brazilian Symposium on Games and Digital Entertainment (SBGames), 2023, pp. 1-10.[4] L. É. Dubois and A. Chalk, "Service Withdrawal: The Uncertain Future of the Games-as-a-Service Model," Convergence, pp. 479-499, 2025.[5] S. A. Hamid, Y. Boujelben, and F. Zarai, "Enhancing Cloud Gaming Experience through Optimized Virtual Machine Placement: A Comprehensive Review," Journal of Network and Systems Management, pp. 1-31, 2024.[6] T. Ishioka, T. Fukui, T. Fujiwara, S. Narikawa, T. Fujihashi, S. Saruwatari, and T. Watanabe, "Traffic Reduction for Speculative Video Transmission in Cloud Gaming Systems," IEICE Transactions on Communications, pp. 408-418, 2024.[7] D. Olliaro, V. Mancuso, P. Castagno, M. Sereno, and M. Ajmone Marsan, "Performance of Distributed Multiparty Online Gaming over Edge Computing Platforms," Computer Communications, pp. 1-14, 2026.[8] K. Rasol, A. Egio, M. Catalan-Cid, L. Lossi, H. Simeão, and S. Siddiqui, "5GaaS: DLT and Smart Contract-Based Network Slice Management in a Decentralized Marketplace," in 20th International Conference on Network and Service Management (CNSM), 2024, pp. 1-7.[9] J. M. Costes and C. Bonnaire, "Spending Money in Free-to-Play Games: Sociodemographic Characteristics, Motives, Impulsivity and Internet Gaming Disorder Specificities," International Journal of Environmental Research and Public Health, pp. 1-14, 2022.[10] Metaplay and Photon, "How to Build a Multiplayer Live Service Game in 2026," Industry Whitepaper, 36 pages, 2026.[11] A. Hatfield, "Games Industry Lens Update for the Well-Architected Framework," AWS Blog, Dec. 10, 2025.[12] AccelByte, "AccelByte Gaming Services (AGS) - Technical Overview," Technical Documentation, Jan. 21, 2026.[13] S. Poueme and A. Hatfield, "Modernize Game Backend Services with AWS Global Accelerator," AWS for Games Blog, Dec. 18, 2024.[14] O. Kuhnke, "Former BioWare Producer Details What Went Wrong With Anthem," GameSpot, Aug. 6, 2025.[15] O. Kuhnke, "As Anthem Approaches Its Shutdown, Ex-BioWare Boss Reflects," GameSpot, Aug. 20, 2025.[16] K. Orland, "Why Reviving the Shuttered Anthem Is Turning Out Tougher Than Expected," Ars Technica, Jan. 28, 2026.[17] R. Gokhale, P. R. Peddareddy, N. Robinson, P. Shireman, and A. Whitehurst, "How Games as a Service (GaaS) and Transmedia Strategies Sustain Video Game Franchises, Part II," Carnegie Mellon University Report, Feb. 11, 2026.[18] EPAM Systems, "Gaming as a Service: Redefining the Way We Play," Industry Whitepaper, 2025.[19] Microsoft, "Supporting Games-as-a-Service (GaaS) - Microsoft Game Development Kit," Technical Documentation, 2025.«اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است»مهسا دباغیانمهسا دباغیانSat, 01 Aug 2026 19:42:04 +0330https://virgool.ir/@m_17421119/تجربه-خوانش-کتاب-game-programming-patterns-x8krerretofcکتاب Game Programming Patterns از Nystrom را در این صفحه می‌خواهیم بررسی کنیم:چرا این کتاب خاص است؟در دنیای انبوه کتاب‌های الگوهای طراحی، کتاب Game Programming Patterns جایگاه منحصربه‌فردی دارد. تفاوت آن در سه محور اساسی است:بسیاری از کتاب‌های الگوهای طراحی، نرم‌افزارهای عمومی مانند سیستم‌های اطلاعاتی و نرم‌افزارهای سازمانی را هدف قرار می‌دهند. اما این کتاب، الگوها را در بستر سخت‌گیرانه‌ترین حوزه نرم‌افزاری بررسی می‌کند؛ محیطی که هر میلی‌ثانیه حیاتی است، حافظه محدود است، و کاربر انتظار پاسخ‌گویی بی‌وقفه دارد. نویسنده با طنز می‌گوید که الگوهای Gang Of Four برای نرم‌افزارهای بانکی نوشته شده‌اند، اما در بازی هیچ‌کس منتظر نمی‌ماند تا تراکنش‌تان تایید شود.Nystrom مثال‌های خود را از چالش‌های واقعی در توسعه بازی می‌گیرد؛ مانند مدیریت هزاران شیء همزمان مثل ذرات، دشمنان و گلوله‌ها، تعامل پیچیده بین سیستم‌های فیزیک، صدا، هوش مصنوعی و رندرینگ، و نیاز به انعطاف‌پذیری برای اضافه کردن فیچرهای جدید بدون تخریب ساختار موجود می‌گوید.برخلاف کتاب‌های خشک دانشگاهی، Nystrom با زبان طنز و مثال‌های عجیب مفاهیم سنگین را شیرین می‌کند. این سبک باعث می‌شود کتاب نه یک منبع مرجع خشک، بلکه یک مکالمه‌ی دوستانه با یک برنامه‌نویس باتجربه باشد. او جایی می‌گوید اگر تا به حال در یک بازی، نیم‌فریم از یک صحنه را دیده‌اید که نصفش کشیده شده و نصفش نه، یعنی Double Buffer خراب شده است و آن لحظه، لعنت به حافظه‌ای که بافر را خراب کرده و من به عنوان یک فرد علاقمند به بازی و بازی‌سازی عمیقا با او همدردی می‌کنم.Game Programming Patterns معماری نرم‌افزار از دیدگاه نویسندهNystrom در مقدمه و فصل اول، یک تز کلیدی مطرح می‌کند که با کلیشه‌های رایج تفاوت اساسی دارد. او معماری در بازی‌ها را هنرِ مدیریتِ پیچیدگی در یک محیطِ با محدودیتِ شدیدِ زمان می‌داند. به عبارت دیگر، در یک نرم‌افزار معمولی مثل یک ویرایشگر متن، کار کردن هدف اصلی است. اما در یک بازی، کار کردنِ سریع و بی‌وقفه هدف است و این تفاوت، همه‌چیز را تغییر می‌دهد.Nystrom در سراسر کتاب، پنج ویژگی کلیدی برای معماری خوب ترسیم می‌کند:جداسازی: سیستم‌ها نباید از وجود یکدیگر مطلع باشند. برای مثال، فیزیک نباید از سیستم دستاوردها خبر داشته باشد.مدیریت زمان: معماری باید کنترل دقیقی بر زمان اجرا داشته باشد. حلقه‌ی بازی باید بتواند سرعت را با سخت‌افزار تطبیق دهد.انعطاف‌پذیری: باید بتوان فیچرهای جدید اضافه کرد بدون تخریب ساختار. الگوی Component امکان اضافه کردن قابلیت پرواز به هر موجودیتی را می‌دهد.کارایی: معماری باید بهینه‌ترین استفاده را از سخت‌افزار ببرد. الگوی Data Locality برای استفاده بهینه از کش CPU طراحی شده است.سادگی: پیچیدگی، دشمن اصلی برنامه‌نویس است. به همین دلیل نویسنده الگوی Singleton را به دلیل پیچیدگی‌هایش رد می‌کند.Nystrom بارها تأکید می‌کند که معماری فقط برای امروز نیست. یک معماری خوب باید بتواند تغییرات آینده را به راحتی جذب کند. او می‌گوید اگر نتوانید به راحتی فیچر جدیدی به بازی اضافه کنید، معماری شما شکست خورده است، حتی اگر امروز عالی کار کند. تفاوت بازی با نرم‌افزارهای معمولیدرک تفاوت بازی‌ها با نرم‌افزارهای معمولی، کلید فهمیدن این کتاب است. نویسنده این تفاوت را در چند محور اساسی توضیح می‌دهد:حلقه‌ی بی‌وقفه:نرم‌افزارهای معمولی منتظر ورودی کاربر می‌مانند و وقتی کاری نیست، بیکار می‌نشینند. اما بازی‌ها هرگز نمی‌ایستند. حتی وقتی کاربر کاری نمی‌کند، انیمیشن‌ها حرکت می‌کنند، هوش مصنوعی تصمیم می‌گیرد، و دنیای بازی به زندگی خود ادامه می‌دهد. این یعنی معماری بازی باید بتواند یک چرخه‌ی بی‌نهایت را به صورت روان مدیریت کند.عملکرد حیاتی: در یک نرم‌افزار حسابداری، اگر پردازش یک تراکنش نیم‌ثانیه طول بکشد، کسی متوجه نمی‌شود. اما در یک بازی، اگر یک فریم بیشتر از ۳۳ میلی‌ثانیه طول بکشد، بازیکن لگ را احساس می‌کند و از بازی دلزده می‌شود. به عبارت دیگر، در بازی‌ها زمان یک منبع حیاتی است که باید به دقت مدیریت شود.مدیریت حافظه: نرم‌افزارهای معمولی می‌توانند حافظه را تخصیص و آزاد کنند و سیستم‌عامل همه‌چیز را جمع‌وجور کند. اما در بازی‌ها، تخصیص و آزادسازی مکرر حافظه باعث خردشدگی حافظه می‌شود و می‌تواند بازی را از کار بیندازد. به همین دلیل، بازی‌ها معمولاً از تخصیص پویا حافظه اجتناب می‌کنند.همزمانی موجودیت‌ها: در یک نرم‌افزار معمولی، ممکن است چند شیء با هم کار کنند، اما تعدادشان محدود است. در یک بازی، ممکن است هزاران موجودیت همزمان وجود داشته باشند؛ هر کدام با رفتار، موقعیت و وضعیت خاص خود قرار دارند. مدیریت این همه موجودیت به صورت همزمان، یک چالش بزرگ معماری است.تغییرپذیری مداوم: نرم‌افزارهای معمولی پس از انتشار، تغییرات کمی می‌کنند. اما بازی‌ها هرگز تمام نمی‌شوند. همیشه فیچر جدید، دشمن جدید، آیتم جدید یا حالت جدید اضافه می‌شود. معماری بازی باید به گونه‌ای باشد که این تغییرات را به راحتی جذب کند.چرا این الگوها برای بازی‌سازی انتخاب شده‌اند؟Nystrom از میان ده‌ها الگوی طراحی، نوزده الگو را انتخاب کرده است. معیار انتخاب او ساده است: الگوهایی که مستقیماً چالش‌های منحصربه‌فرد بازی‌سازی را حل می‌کنند.چالش حلقه‌ی بی‌وقفه: برخلاف نرم‌افزارهای معمولی که منتظر ورودی کاربر می‌مانند، بازی‌ها همیشه در حال اجرا هستند، حتی وقتی کاربر کاری نمی‌کند. الگوی راه‌حل، Game Loop است. نویسنده با طنز می‌گوید که بازی‌ها مثل یک دیوانه‌ی خوش‌حال هستند که هیچ‌وقت نمی‌ایستند و باید بتوانی با آن‌ها مسابقه دو بدهی.چالش انفجار موجودیت‌ها: در یک بازی، ممکن است صدها یا هزاران موجودیت همزمان وجود داشته باشند؛ مانند دشمنان، گلوله‌ها، ذرات و آیتم‌ها. الگوی راه‌حل، Object Pool و Component است. نویسنده می‌گوید اگر برای هر گلوله‌ای که شلیک می‌شود، حافظه تخصیص دهید، بازی شما مثل یک لک‌لکِ پرخور، حافظه را می‌بلعد و هضم نمی‌کند.چالش حالت‌های متعدد: یک کاراکتر بازی ممکن است در حالت‌های مختلفی باشد: ایستاده، در حال دویدن، پریدن، شیرجه، و غوطه‌وری. ترکیب این حالت‌ها با عوامل دیگر مثل سلاح در دست می‌تواند به انفجار حالات منجر شود. الگوی راه‌حل، State و Hierarchical State Machine است. نویسنده می‌گوید به جای اینکه هزاران شرط if بنویسید، هر حالت را به یک کلاس مجزا تبدیل کنید تا اگر ایرادی باشد، فقط یک کلاس را و نه کل بازی را عوض کنید.چالش ارتباطات بین‌سیستمی: سیستم‌های مختلف بازی مانند فیزیک، صدا، هوش مصنوعی و رندرینگ باید با هم ارتباط داشته باشند، اما نباید از وجود یکدیگر مطلع باشند. الگوی راه‌حل، Observer، Event Queue و Service Locator است. نویسنده می‌گوید سیستم‌های بازی مثل همسایه‌های بداخلاق در یک آپارتمان هستند؛ باید بتوانند از هم باخبر شوند، بدون اینکه به درِ هم بزنند.چالش تغییرپذیری و افزودن فیچر: بازی‌ها هرگز تمام نمی‌شوند؛ همیشه فیچر جدید، دشمن جدید، یا آیتم جدید اضافه می‌شود. الگوی راه‌حل، Type Object، Component و Bytecode است. نویسنده می‌گوید بازی‌ها مثل یک رستوران هستند که هر روز غذای جدید به منو اضافه می‌کنند و اگر برای هر غذا یک آشپزخانه‌ی جدید بسازید، دیوانه شده‌اید.چالش مدیریت حافظه: تخصیص و آزادسازی مکرر حافظه در بازی‌ها منجر به خردشدگی حافظه می‌شود که می‌تواند بازی را از کار بیندازد. الگوی راه‌حل، Object Pool و Flyweight است. نویسنده می‌گوید تخصیص حافظه در بازی مثل پارک کردن در خیابان‌های شلوغ است؛ اگر ماشین‌ها را مرتب نکنید، جای پارک برای ماشین جدید پیدا نمی‌کنید.هنر معماری در بازی‌سازیپس از مطالعه‌ی این کتاب، این درک دریافت می‌شود که معماری نرم‌افزار در بازی‌سازی، چیزی فراتر از انتخاب الگوی درست است. این یک هنر است که شامل موارد زیر می‌شود:تشخیص چالش‌های منحصربه‌فرد: بازی‌ها با نرم‌افزارهای معمولی تفاوت اساسی دارند و درک این تفاوت‌ها، اولین قدم برای معماری خوب است.انتخاب الگوی مناسب برای چالش مناسب: هر الگو برای حل یک چالش خاص طراحی شده است و انتخاب الگوی اشتباه، بدتر از عدم استفاده از الگو است.تعادل بین سادگی و پیچیدگی: Nystrom بارها تأکید می‌کند که سادگی، مهم‌ترین ویژگی معماری خوب است. اما گاهی برای حل چالش‌های پیچیده، به الگوهای پیچیده‌تر نیاز داریم.پذیرش تغییرات: بازی‌ها هرگز تمام نمی‌شوند و معماری باید به گونه‌ای باشد که اضافه کردن فیچرهای جدید، آسان و بدون تخریب ساختار موجود باشد.اولویت با عملکرد: در بازی‌ها، عملکرد از خوانایی یا زیبایی کد مهم‌تر است و معماری باید به گونه‌ای باشد که بازی روان اجرا شود. کتاب Game Programming Patterns، یک منبع ارزشمند برای هر بازی‌ساز است. اما فراتر از آن، این کتاب به ما یاد می‌دهد که معماری نرم‌افزار یک هنر است. هنرِ تشخیص چالش‌ها، انتخاب راه‌حل‌های مناسب، و ایجاد تعادل بین سادگی، انعطاف‌پذیری و عملکرد. Nystrom با سبک طنز و صمیمی خود، مفاهیم سنگین را شیرین می‌کند و نشان می‌دهد که معماری نرم‌افزار می‌تواند جدی ولی خشک نباشد. او به ما یادآوری می‌کند که در نهایت، هدف ما از معماری، ساختن بازی‌هایی است که مردم دوست داشته باشند، نه صرفاً کدی که از نظر تئوری درست باشد.به عنوان کسی که همیشه به بازی‌سازی علاقه داشته‌ام، خواندن این کتاب برای من مثل پیدا کردن یک نقشه‌ی گنج بود.چندین بار در حین مطالعه، به پروژه‌های کوچکی که قبلاً نوشته بودم فکر می‌کردم و با خودم می‌گفتم انگار ناخوداگاه به این الگو ها در زمان نوشتن کد فکر کرده‌ام و حتی تا حدودی مانند آنها کدنویسی کرده‌ام یا اگر آن موقع این الگو را می‌دانستم، خیلی زودتر می‌توانستم بازی را به پایان برسانم. همان موقع بود که فهمیدم چرا بعضی از بازی‌های مستقل اینقدر سریع ساخته می‌شوند؛ چون از ابتدا معماری درستی دارند و معماری نجات‌بخش است. یا گاها طراح بازی ایونتی در ذهنش نقش می‌بند و کد اجرایی را می خواهد و قرار نیست این کد دور ریخته شود و معماری درستی ندارد و همه چیز را به دردسر می‌اندازد.بهتر است سری به محتوای این کتاب بزنیمتحلیل و کاربرد هر الگو در بازی‌سازیالگوی Command: این الگو تبدیل درخواست به یک شیء برای مدیریت ورودی، صف‌بندی، و قابلیت Undo/Redo است. در بازی برای مدیریت ورودی کاربر، شبکه و مالتی‌پلیر، ضبط و پخش مجدد، و سیستم Undo/Redo در ادیتورهای سطح کاربرد دارد. نویسنده با طنز می‌گوید که تعریف گانگ آف فور از Command، یکی از افتضاح‌ترین جملاتی است که تا به حال خوانده‌ام و به زبان ساده یعنی یک تابع را تبدیل به یک شیء می‌کنیم تا بتوانیم آن را در یک متغیر ذخیره کنیم، به یک تابع دیگر بفرستیم، یا حتی آن را از طریق شبکه ارسال کنیم.Nystromتعریف گانگ آف فور از Command، را به یکی از افتضاح‌ترین جملاتی است که تا به حال خوانده‌است تشبیه می‌کند. "یک درخواست را به عنوان یک شیء کپسوله کنید..." یعنی چی؟ مگر می‌شود یک مشتری را پارامتریزه کرد!الگوی Flyweight: این الگو برای به‌اشتراک‌گذاری داده‌های تکراری بین اشیاء مشابه به منظور کاهش مصرف حافظه استفاده می‌شود. در بازی برای جنگل‌های هزاران درخت، سیستم تایل، و بهینه‌سازی رندر کاربرد دارد. نویسنده می‌گوید Flyweight یعنی داده‌های مشترک را در یک جا نگه داریم و همه‌ی اشیاء به آن اشاره کنند، مثل این است که همه‌ی سربازان یک ارتش، از یک مدل کلاه استفاده کنند و درختان یک جنگل، همه شبیه هم هستند.Nystrom می‌گوید که: درختان یک جنگل، همه شبیه هم هستند. مگر اینکه دیوانه باشید یا میلیاردر که هنرمندان را استخدام کنید تا هر درخت را جداگانه مدل‌سازی کنید!الگوی Observer: این الگو برای ارتباط غیرمستقیم بین سیستم‌ها بدون وابستگی مستقیم طراحی شده است. در بازی برای سیستم دستاوردها، سیستم صدا، و به‌روزرسانی UI کاربرد دارد. نویسنده می‌گوید Observer یعنی یک سیستم فریاد می‌زند که من نمی‌دانم چه کسی گوش می‌دهد، اما این اتفاق افتاد و هرکس که علاقه‌مند است، پیام را دریافت می‌کند. این الگو آنقدر فراگیر است که جاوا آن را در کتابخانه‌ی اصلی خود قرار داد و سی‌شارپ آن را به عنوان کلیدواژه‌ی event به زبان اضافه کرد.از نظر او این الگو آنقدر فراگیر است که جاوا آن را در کتابخانه‌ی اصلی خود قرار داد و سی‌شارپ آن را به عنوان کلیدواژه‌ی event به زبان اضافه کرد. انگار که این الگو، پدرخوانده‌ی دنیای نرم‌افزار است!الگوی Prototype: این الگو برای ایجاد اشیاء جدید با کپی کردن از یک شیء نمونه یا کلون کردن استفاده می‌شود. در بازی برای سیستم اسپاون و تولید موجودیت‌های مشابه با تنظیمات متفاوت کاربرد دارد. نویسنده می‌گوید Prototype یعنی یک شیء بتواند از خودش کپی بگیرد و اگر یک Ghost دارید، می‌توانید از آن Ghostهای بیشتری بسازید. این الگو در سال ۱۹۶۳ توسط ایوان ساترلند در پروژه‌ی Sketchpad اختراع شد.Nystrom می‌گوید : این الگو در سال ۱۹۶۳ توسط ایوان ساترلند در پروژه‌ی Sketchpad اختراع شد. در همان سالی که بقیه داشتند به بیتلز و دیلن گوش می‌دادند، او مشغول اختراع مفاهیم پایه‌ای CAD، گرافیک تعاملی و برنامه‌نویسی شی‌گرا بود.الگوی Singleton: نویسنده این الگو را به دلایل مختلف رد می‌کند. او می‌گوید Singleton یک متغیر سراسری است و همه‌ی مشکلات متغیرهای سراسری را دارد. همچنین دو مشکل را با یک راه‌حل حل می‌کند؛ محدودیت به یک نمونه با دسترسی سراسری دو مسئله‌ی مجزا هستند. او راهکارهای جایگزینی مانند Static Class، ارسال به عنوان پارامتر، و Service Locator را پیشنهاد می‌دهد.الگوی State این الگو برای مدیریت حالت‌های مختلف یک شیء بدون استفاده از شرط‌های پیچیده استفاده می‌شود. در بازی برای حالت‌های کاراکتر، هوش مصنوعی، و منوی بازی کاربرد دارد. نویسنده می‌گوید State یعنی هر حالت را به یک کلاس مجزا تبدیل کنیم و وقتی کاراکتر در حال پریدن است، فقط کدهای مربوط به پرش اجرا می‌شوند. ماشین حالت از دل تئوری اتوماتا آمده، اما State Machine ساده‌ترین عضو این خانواده است.الگوی Double Buffer: این الگو برای نمایش یک فریم کامل، بدون نمایان شدن مراحل میانی رندرینگ استفاده می‌شود. در بازی برای رندرینگ گرافیکی، سیستم فیزیک، و سیستم صدا کاربرد دارد. نویسنده می‌گوید Double Buffer یعنی دو صحنه‌ی تئاتر داشته باشیم و در یکی نمایش اجرا می‌شود و در دیگری، صحنه‌ی بعدی آماده می‌شود. وقتی نمایش تمام شد، چراغ‌ها را عوض می‌کنیم و نمایش جدید بدون وقفه شروع می‌شود.الگوی Game Loop: این الگو برای جدا کردن زمان بازی از سرعت پردازنده و ورودی کاربر طراحی شده است. در بازی قلب هر بازی محسوب می‌شود و برای تطبیق با سخت‌افزارهای مختلف و مدیریت زمان کاربرد دارد. نویسنده می‌گوید Game Loop یعنی بازی هرگز منتظر ورودی کاربر نمی‌ماند و همیشه در حال چرخش است. اگر کاربر کاری نکند، باز هم انیمیشن‌ها حرکت می‌کنند، جلوه‌های ویژه می‌درخشند، و هیولاها قهرمان ما را می‌جوند.در اینجا هم او بامزه می‌گوید: در روزگار قدیم، کامپیوترها دکمه‌ی Turbo داشتند. چون بازی‌های قدیمی روی کامپیوترهای جدید خیلی سریع اجرا می‌شدند و غیرقابل بازی بودند. حالا ما باید خودمان این کار را با کد انجام دهیم!الگوی Update Method: این الگو برای شبیه‌سازی رفتار همزمان موجودیت‌های مستقل استفاده می‌شود. در بازی برای هر موجودیت در بازی و سیستم‌های مستقل کاربرد دارد. نویسنده می‌گوید Update Method یعنی به هر موجودیت بگوییم در این فریم، یک قدم از رفتارت را انجام بده. اگر یک اسکلت گشت‌زن دارید که باید به چپ و راست برود، به جای اینکه یک حلقه‌ی بی‌نهایت بنویسید و بازی را قفل کنید، به آن یک متد update بدهید که هر فریم یک قدم بردارد.الگوی Bytecode: این الگو برای تعریف رفتار به صورت داده، برای ایمنی و انعطاف‌پذیری استفاده می‌شود. در بازی برای سیستم جادوها، هوش مصنوعی، و مودینگ کاربرد دارد. نویسنده می‌گوید Bytecode یعنی رفتار را به صورت داده تعریف کنیم و یک ماشین مجازی کوچک آن را اجرا کند. اینطوری، رفتارهای جدید را می‌توان بدون کامپایل مجدد، و در محیطی امن اجرا کرد.الگوی Subclass Sandbox این الگو برای تعریف رفتار در زیرکلاس‌ها با استفاده از عملیات‌های پایه‌ای که کلاس پایه فراهم می‌کند، استفاده می‌شود. در بازی برای سیستم ابرقدرت‌ها و سیستم آیتم‌ها کاربرد دارد. نویسنده می‌گوید Subclass Sandbox یعنی به زیرکلاس‌ها یک جعبه‌ی شنی از ابزارها بدهیم و به آن‌ها بگوییم با این ابزارها هر کاری دوست دارید بکنید، اما از جعبه‌ی شنی خارج نشوید.«اگر صد تا ابرقدرت دارید و هرکدام مستقیم به سیستم صدا متصل است، وقتی سیستم صدا عوض می‌شود، باید صد تا کلاس را عوض کنید. اما اگر همه از طریق کلاس پایه به صدا متصل شوند، فقط یک کلاس را عوض می‌کنید.الگوی Type Object: این الگو برای ایجاد نوع‌های جدید بدون تعریف کلاس‌های جدید استفاده می‌شود. در بازی برای گونه‌های دشمنان، سیستم آیتم‌ها، و سیستم جادوها کاربرد دارد. نویسنده می‌گوید Type Object یعنی به جای اینکه برای هر گونه دشمن، یک کلاس جدید تعریف کنیم، یک کلاس به نام Breed داریم که هر نمونه‌اش، یک گونه‌ی جدید را تعریف می‌کند."اگر دویست گونه دشمن دارید و هرکدام یک کلاس مجزا هستند، روزگار شما به این می‌گذرد که ایمیل طراحان را بخوانید، یک عدد را در یک کلاس عوض کنید، کامپایل کنید، و دوباره ایمیل بفرستید. این الگو شما را از این کار نجات می‌دهد"الگوی Component: این الگو برای جداسازی دامنه‌های مختلف یک موجودیت بدون وابستگی به یکدیگر استفاده می‌شود. در بازی برای موجودیت‌های بازی و ساخت اشیاء ترکیبی کاربرد دارد. نویسنده می‌گوید Component یعنی موجودیت را به قطعات کوچک و مستقل تقسیم کنیم و فیزیک از رندرینگ خبر ندارد و رندرینگ از هوش مصنوعی خبر ندارد.Component مثل یک رستوران سلف‌سرویس است. شما می‌توانید فقط سالاد، فقط سوپ، یا ترکیبی از هر دو را انتخاب کنید. برخلاف منوی تکراری که هر ترکیب، یک غذای جداگانه است!الگوی Event Queue: این الگو برای جداسازی زمان ارسال رویداد از زمان پردازش آن استفاده می‌شود. در بازی برای سیستم صدا، ارتباط بین‌سیستمی، و مدیریت ورودی کاربرد دارد. نویسنده می‌گوید Event Queue یعنی درخواست‌ها را در یک صف قرار دهیم و بعداً پردازش کنیم.الگوی Service Locator: این الگو برای دسترسی سراسری به سرویس‌ها بدون وابستگی به پیاده‌سازی خاص استفاده می‌شود. در بازی برای سیستم صدا، سیستم لاگ، و سیستم فایل کاربرد دارد. نویسنده می‌گوید Service Locator مثل دفترچه تلفن است و هرکس نیاز به سرویسی دارد، در دفترچه تلفن نگاه می‌کند. وقتی سرویس عوض می‌شود، فقط دفترچه تلفن را عوض می‌کنیم، نه همه‌ی افرادی که از آن استفاده می‌کنند.الگوی Data Locality: این الگو برای چیدمان داده‌ها در حافظه برای استفاده بهینه از کش CPU استفاده می‌شود. در بازی برای آرایه‌های پیوسته برای کامپوننت‌ها، مرتب‌سازی اشیاء بر اساس وضعیت فعال، و جداسازی داده‌های داغ و سرد کاربرد دارد. نویسنده می‌گوید Data Locality یعنی داده‌هایی که با هم پردازش می‌شوند را کنار هم در حافظه قرار دهیم.الگوی Dirty Flag: این الگو برای به‌روزرسانی فقط زمانی که داده تغییر کرده است استفاده می‌شود. در بازی برای صحنه‌گراف، ذخیره‌سازی خودکار، و به‌روزرسانی UI کاربرد دارد. نویسنده می‌گوید Dirty Flag یعنی به‌جای اینکه هر بار همه‌چیز را محاسبه کنیم، فقط وقتی داده تغییر کرده است، محاسبه را انجام دهیم.الگوی Object Pool: این الگو برای استفاده مجدد از اشیاء به جای تخصیص و آزادسازی مکرر استفاده می‌شود. در بازی برای سیستم ذرات، گلوله‌ها، و دشمنان کاربرد دارد. نویسنده می‌گوید Object Pool یعنی یک مجموعه از اشیاء از پیش تخصیص‌داده‌شده داشته باشیم و وقتی به شیء جدید نیاز داریم، از این مجموعه برمی‌داریم و وقتی تمام شد، به مجموعه برمی‌گردانیم.الگوی Spatial Partition: این الگو برای پیدا کردن سریع اشیاء بر اساس موقعیت مکانی استفاده می‌شود. در بازی برای برخورد‌یابی، رندرینگ، و هوش مصنوعی کاربرد دارد. نویسنده می‌گوید Spatial Partition یعنی اشیاء را بر اساس موقعیت مکانی در یک ساختار داده سازماندهی کنیم تا برای پیدا کردن اشیاء نزدیک به یک نقطه، نیازی به بررسی همه‌ی اشیاء نداشته باشیم.مهسا دباغیانمهسا دباغیانFri, 10 Jul 2026 20:17:10 +0330https://virgool.ir/@m_17421119/اکوسیستم-توسعه-مبتنی-بر-unreal-در-riot-games-q7buqfzpgyp6عنوان سخنرانی: Riot's Multi-Game Unreal-Based Development Ecosystemکنفرانس: Unreal Fest Seattle 2024سخنران: Daniel (مهندس تیم اکوسیستم Unreal, Riot Games)تاریخ ارائه: سپتامبر ۲۰۲۴لینک ویدیو: https://youtu.be/9xxwQVdwcTQ?si=V6SekznnI8KYQVGwخلاصه فنیدنیل، مهندس تیم اکوسیستم Unreal در Riot Games، در این سخنرانی به بررسی معماری و عملکرد اکوسیستم توسعه بازی مشترک در Riot می‌پردازد. این اکوسیستم با نام Core SDK شناخته می‌شود و هدف آن کاهش سربار توسعه و افزایش بهره‌وری در ساخت بازی‌های AAA است.مشکل اصلی که Riot با آن مواجه است، تکرار تلاش‌های فنی در تیم‌های مختلف بازی است. هر تیم برای راه‌اندازی یک بازی چندنفره، نیاز به پیاده‌سازی مجدد فناوری‌های مشترک مانند احراز هویت، شبکه‌های اجتماعی، تله‌متری و تامین سرور دارد. این سربار، تیم‌ها را از تمرکز بر روی گیم‌پلی و تجربه بازیکن دور می‌کند.راه‌حل Riot، ایجاد یک اکوسیستم توسعه مشترک است که در آن فناوری‌های بازی-محور به صورت آماده در اختیار تیم‌ها قرار می‌گیرند. اهداف سطح بالای اکوسیستم عبارتند از: اجازه تمرکز توسعه‌دهندگان بر ساخت بازی‌های عالی، باز بودن اکوسیستم برای پذیرش مشارکت‌ها از همه تیم‌ها، ایجاد مجموعه‌ای از بهترین شیوه‌ها و استانداردهای مشترک، و داشتن یک تیم مرکزی برای هدایت و تکامل اکوسیستم که تیم Unico نامیده می‌شود.Riotمعماری Core SDK بر پایه یک ساختار دایرکتوری استاندارد برای همه بازی‌ها و تیم‌ها استوار است. پوشه Core SDK که کاملاً از پوشه موتور Unreal جدا است، شامل تمام افزونه‌ها، اصلاحات موتور و فناوری‌های مشترک می‌شود. این ساختار استاندارد، جابجایی استعدادها بین تیم‌ها را تسهیل می‌کند و به وضوح فناوری Riot را از فناوری Epic جدا می‌سازد.کنترل نسخه در Riot بر پایه Perforce است و همه تیم‌ها در یک استقرار واحد از سرور Perforce زندگی می‌کنند. این یکپارچگی، امکان ادغام‌های گزینشی و مشارکت‌های بالادستی را ساده‌تر می‌کند. تیم Unico تنها تیمی است که مسئول دریافت نسخه‌های UE و ارتقاء Core SDK است و این ارتقاء را یک بار برای همه تیم‌های بازی انجام می‌دهد. هر تیم بازی انبار مخصوص به خود را دارد و با استفاده از زنجیره‌ای از جریان‌های استاندارد، نسخه‌های جدید Core SDK را دریافت و با بازی خود ادغام می‌کند.اصلاحات موتور زمانی انجام می‌شوند که تیم Unico مجبور به تغییر موتور Unreal می‌شود. این اصلاحات با برچسب‌گذاری دقیق و فرآیند ثبت‌نام صریح انجام می‌شوند. نمونه‌هایی از این اصلاحات شامل یکپارچه‌سازی Fast Build برای شتاب‌دهی ساخت و بهبود قابلیت‌های پروفایل‌سازی با Unreal Insight است. در یکپارچه‌سازی Fast Build، Riot از CDN شرکت و پچر مخصوص بازیکنان برای توزیع حافظه‌های نهان فایل‌های شیء استفاده می‌کند.افزونه‌های مشترک Core SDK، پل ارتباطی بین بازی‌ها و سرویس‌های آنلاین Riot هستند. این افزونه‌ها تجربه ورود یکنواخت، ویژگی‌های اجتماعی مانند لیست دوستان و چت، و یکپارچه‌سازی با پلتفرم تامین سرور بازی را فراهم می‌کنند. افزونه تحلیلی، امکان تعریف رویدادهای تله‌متری در C++ یا Blueprint را می‌دهد و چارچوب متریک، جمع‌آوری داده‌های عملکردی را استاندارد می‌کند.زیرساخت‌های مشترک شامل Horde و Build Graph برای اتوماسیون ساخت، Robo Merge برای مدیریت ادغام‌ها، و Unreal Game Sync به عنوان نقطه ورود توسعه‌دهندگان به اکوسیستم است. Riot با اصلاح این ابزارها، قابلیت‌هایی مانند پیکربندی مبتنی بر JSON، مقیاس‌بندی خودکار، و توزیع نسخه‌های ویرایشگر از طریق CDN را اضافه کرده است.فلسفه توسعه تیم Unico بر مشارکت عمیق با تیم‌های بازی، همگرایی راه‌حل‌های پراکنده به یک مسیر طلایی، و پذیرش مشارکت‌های بالادستی از تیم‌های بازی و سایر تیم‌های فنی استوار است. با وجود موفقیت‌ها، چالش‌هایی مانند نابالغی فرآیندهای تضمین کیفیت، سربار سنگین کار پشتیبانی برای تیم کوچک Unico، و پیچیدگی ادغام‌های مداوم با نسخه‌های جدید Epic و مشارکت‌های تیم‌های بازی وجود دارد.برداشت شخصینکات جدید و جالب برای مناین سخنرانی برای من بسیار جذاب بود و چندین نکته جدید و ارزشمند داشت. اولین و مهم‌ترین نکته، مفهوم اکوسیستم توسعه مشترک در مقیاس یک شرکت بزرگ بازی‌سازی بود. پیش از این، تصور می‌کردم که هر تیم بازی به صورت مستقل و با حداقل اشتراک فناوری کار می‌کند، اما رویکرد Riot در ایجاد Core SDK و استانداردسازی عمیق، دیدگاه جدیدی به من داد. این رویکرد نه تنها سربار تیم‌های جدید را کاهش می‌دهد، بلکه جابجایی استعدادها را نیز تسهیل می‌کند.دومین نکته جالب، ساختار دایرکتوری استاندارد و جداسازی کامل Core SDK از موتور Unreal بود. این جداسازی به Riot اجازه می‌دهد که کنترل دقیق‌تری بر فناوری‌های اختصاصی خود داشته باشد و همزمان ارتقاء موتور از اپیک را با سهولت بیشتری مدیریت کند.سومین نکته، مدیریت متمرکز نسخه‌های موتور و فرآیند ارتقاء بود. اینکه فقط تیم Unico مسئول دریافت نسخه‌های جدید UE و انجام اصلاحات موتور است و سپس این ارتقاء را یک بار برای همه تیم‌ها منتشر می‌کند، بسیار کارآمد به نظر می‌رسد.چهارمین نکته، فلسفه توسعه مشارکتی و پذیرش مشارکت‌های بالادستی بود. Riot به جای اینکه تیم Unico را به عنوان یک تیم جداگانه و تصمیم‌گیرنده منفرد در نظر بگیرد، اکوسیستم را به گونه‌ای طراحی کرده که تیم‌های بازی و سایر تیم‌های فنی بتوانند به راحتی در توسعه Core SDK مشارکت کنند.ارتباط با مباحث درسی معماری نرم‌افزاراین سخنرانی ارتباط عمیقی با چندین مفهوم کلیدی در معماری نرم‌افزار دارد.ارتباط اول، معماری مبتنی بر پلتفرم است. رویکرد Riot در ایجاد Core SDK، یک نمونه عملی از معماری مبتنی بر پلتفرم است که در آن یک لایه مشترک از قابلیت‌ها، زیربنای توسعه چندین محصول قرار می‌گیرد. این معماری، مزایای استفاده مجدد از کد و کاهش هزینه‌های توسعه را به همراه دارد.ارتباط دوم، مدیریت پیکربندی و کنترل نسخه است. استفاده از Perforce با ساختار جریان‌های استاندارد و مدیریت متمرکز ارتقاءها، نمونه‌ای از بهترین شیوه‌های مدیریت کد در مقیاس بزرگ محسوب می‌شود.ارتباط سوم، معماری افزونه‌ها است. Core SDK با ارائه افزونه‌های متعدد برای قابلیت‌های مختلف مانند احراز هویت، شبکه‌های اجتماعی و تله‌متری، از معماری مبتنی بر افزونه استفاده می‌کند که امکان توسعه و جایگزینی ماژولار را فراهم می‌کند.ارتباط چهارم، مدیریت ریسک و نسخه‌سازی است. سیاست Riot در ارائه ویژگی‌های جدید به صورت اختیاری و ارائه کنترل به تیم‌های بازی برای انتخاب زمان ارتقاء، نمونه‌ای از مدیریت ریسک در استقرار نرم‌افزار است.نکات انتقادی و سوالات ایجاد شدهبا وجود موفقیت‌های چشمگیر، چند سوال و نکته انتقادی برای من ایجاد شد.سوال اول اینکه با توجه به اینکه تیم Unico تنها حدود ۲۰ نفر است، چگونه می‌توانند از عهده پشتیبانی از بیش از صد افزونه و چندین بازی در مراحل مختلف توسعه برآیند؟ سخنران به چالش سربار پشتیبانی اشاره کرد و آن را «مارپیچ مرگ شغلی» نامید. آیا راه‌حلی مانند واگذاری مالکیت برخی افزونه‌ها به تیم‌های بازی که آنها را ایجاد کرده‌اند، می‌تواند موثر باشد؟سوال دوم اینکه فرآیند پذیرش مشارکت‌های بالادستی از تیم‌های بازی چقدر کارآمد است؟ با توجه به اینکه تیم‌های بازی تحت فشار برای ارائه بازی‌های خود هستند، آیا آنها زمان کافی برای مستندسازی و اجتماعی کردن تغییرات خود با Unico دارند؟سوال سوم اینکه با وجود تمام استانداردسازی‌ها، چه عواملی باعث می‌شود که تیم‌های بازی همچنان راه‌حل‌های خاص خود را ایجاد کنند؟ آیا این به دلیل عدم آگاهی از قابلیت‌های Core SDK است، یا به دلیل نیازهای خاصی که Core SDK پوشش نمی‌دهد؟نکته انتقادی اینکه رویکرد «اقتباس و همگرایی» که در آن Unico ابتدا راه‌حل‌های مختلف را مشاهده می‌کند و سپس سعی در همگرایی آنها دارد، ممکن است باعث شود که برخی تیم‌ها برای مدت طولانی از مسیر طلایی خارج باشند. آیا بهتر نیست Unico راه‌حل‌های طلایی را زودتر ارائه دهد و تیم‌ها را به سمت آنها هدایت کند؟جمع‌بندی شخصیاین سخنرانی یکی از جامع‌ترین و کاربردی‌ترین ارائه‌هایی بود که در زمینه توسعه بازی در مقیاس بزرگ دیده‌ام. Riot Games با ایجاد اکوسیستم Core SDK، نشان داده است که چگونه می‌توان با استانداردسازی، اشتراک‌گذاری فناوری و ایجاد یک تیم مرکزی توانمند، هزینه‌های توسعه را کاهش داد و بهره‌وری را افزایش داد.مهم‌ترین درسی که از این سخنرانی گرفتم، اهمیت تعادل بین استانداردسازی و انعطاف‌پذیری است. Riot با ارائه ساختار استاندارد و افزونه‌های آماده، از یک سو، و اجازه مشارکت و سفارشی‌سازی به تیم‌های بازی، از سوی دیگر، این تعادل را به خوبی برقرار کرده است.همچنین، چالش‌های پیش روی Unico مانند سربار پشتیبانی، نابالغی فرآیندهای تضمین کیفیت، و پیچیدگی ادغام‌ها، نشان می‌دهد که ایجاد یک اکوسیستم مشترک یک سرمایه‌گذاری بلندمدت است و نیازمند تعهد مستمر و بهبود مداوم می‌باشد.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. منابع- Riot Games. (2024). Riot's Multi-Game Unreal-Based Development Ecosystem. Unreal Fest Seattle 2024. Retrieved from https://youtu.be/9xxwQVdwcTQ?si=V6SekznnI8KYQVGwمهسا دباغیانمهسا دباغیانThu, 09 Jul 2026 14:24:01 +0330https://virgool.ir/@m_17421119/data-oriented-design-in-practice-tbon1sgpunf7عنوان سخنرانی: Data-Oriented Design in Practiceسخنران: Andrew Kelley (رئیس و توسعه‌دهنده ارشد نرم‌افزار بنیاد Zig)لینک ویدیو: https://youtu.be/IroPQ150F6c?si=f9EH5p-AalCJeQOyتاریخ ارائه: 2024 خلاصه فنیAndrew Kelley، رئیس و توسعه‌دهنده ارشد نرم‌افزار بنیاد ZIG ، در این سخنرانی به بررسی اصول طراحی داده‌محور و کاربرد عملی آنها در بهینه‌سازی کامپایلر می‌پردازد. او با بیان داستان شخصی خود از یادگیری برنامه‌نویسی و مواجهه با مفاهیم طراحی داده‌محور، سفر خود را از یک توسعه‌دهنده مبتدی تا درک عمیق این رویکرد روایت می‌کند.سخنرانی با یک درس اساسی درباره معماری کامپیوتر آغاز می‌شود: پردازنده سریع است اما حافظه اصلی کند است. تفاوت سرعت بین حافظه نهان سطح اول (و حافظه اصلی چندین مرتبه بزرگی است. این شکاف عملکردی، انگیزه اصلی طراحی داده‌محور، کاهش دسترسی به حافظه با فشرده‌سازی داده‌ها و بهبود محلیت مرجع را شکل می‌دهد: .بخش تعاملی سخنرانی، نحوه چیدمان ساختارها در حافظه را بررسی می‌کند. مفاهیم تراز طبیعی، padding، و اندازه ساختارها با مثال‌های عملی توضیح داده می‌شوند. برای نمونه، یک ساختار با دو فیلد u32 و یک فیلد boolean، بدون بهینه‌سازی ۸ بایت و با چیدمان بهینه ۵ بایت اشغال می‌کند. در مثالی دیگر، یک ساختار با سه فیلد u32، u64، u32، ۲۴ بایت اشغال می‌کند، اما با جابجایی فیلدها، اندازه آن به ۱۶ بایت کاهش می‌یابد.پنج استراتژی عملی برای کاهش ردپای حافظه معرفی می‌شوند. نخست، استفاده از شاخص‌ها به جای اشاره‌گرها که در پردازنده‌های ۶۴ بیتی، اندازه هر فیلد را از ۸ بایت به ۴ بایت کاهش می‌دهد. دوم، ذخیره داده‌های بولی خارج از باند با استفاده از آرایه‌های جداگانه برای موجودیت‌های زنده و مرده که هم حافظه و هم بررسی‌های شرطی در حلقه‌ها را کاهش می‌دهد. سوم، استفاده از آرایه‌های سازنده به جای آرایه‌ای از ساختارها که padding بین عناصر را حذف می‌کند. چهارم، ذخیره داده‌های پراکنده در hashmap‌ها برای مواردی که اکثر موجودیت‌ها مقدار خاصی ندارند. و پنجم، استفاده از رویکرد کدگذاری به جای چندریختی که با کدگذاری برچسب‌ها و داده‌های مشترک در ساختارهای متفاوت، اندازه هر موجودیت را به طور چشمگیری کاهش می‌دهد.مطالعه موردی کامپایلر زیگ نشان می‌دهد که این استراتژی‌ها در دنیای واقعی مؤثر هستند. اندازه هر توکن از ۶۴ بایت به ۵ بایت کاهش یافت که کاهشی ۹۲ درصدی را نشان می‌دهد. زمان اجرای کل فرایند توکن‌سازی ۲۲ درصد سریع‌تر شد. اندازه گره‌های درخت نحو از میانگین ۵۴ بایت به ۲۰.۳ بایت کاهش یافت که به بهبود ۳۹ درصدی در زمان اجرا منجر شد. با موازی‌سازی بخش‌هایی از خط لوله، سرعت پردازش به ۸.۹ میلیون خط کد در ثانیه رسید. خروجی این بخش از خط لوله اکنون فقط چهار آرایه است که به راحتی با یک فراخوان سیستمی روی دیسک ذخیره یا بارگذاری می‌شود.Data-Oriented برداشت شخصینکات جدید و جالب برای مناین سخنرانی برای من بسیار جالب و پر از نکات جدید بود. اولین و مهم‌ترین نکته، تفاوت چشمگیر سرعت بین حافظه نهان و حافظه اصلی بود. این واقعیت که انجام محاسبات ریاضی از خواندن از حافظه L1 نیز سریع‌تر است، یک دیدگاه کاملاً جدید به من داد. این یعنی گاهی بهتر است یک مقدار را دوباره محاسبه کنیم تا اینکه آن را در حافظه ذخیره و بازیابی کنیم.دومین نکته جالب، مفهوم padding و نحوه تأثیر ترتیب فیلدها بر اندازه ساختارها بود. مثالی که یک boolean یک بیتی باعث افزایش ۸ بایتی اندازه ساختار می‌شود (از ۱۶ به ۲۴ بایت)، بسیار شگفت‌انگیز بود. این نشان می‌دهد که طراحی ساده داده‌ها چقدر می‌تواند بر مصرف حافظه تأثیر بگذارد.سومین نکته، استراتژی‌های عملی مانند استفاده از آرایه‌های سازنده به جای آرایه‌ای از ساختارها بود. این ترفند ساده padding را حذف می‌کند و علاوه بر کاهش حافظه، محلیت مرجع را نیز بهبود می‌بخشد. همچنین ذخیره داده‌های پراکنده در hashmap و ذخیره بولی‌ها خارج از باند، ایده‌های خلاقانه‌ای بودند که نشان می‌دهند چگونه می‌توان داده‌ها را بر اساس الگوهای دسترسی سازماندهی کرد.چهارمین نکته، رویکرد کدگذاری به جای چندریختی بود. کدگذاری برچسب‌ها و داده‌های مشترک در ساختارهای مختلف، به جای استفاده از اتحادیه‌های برچسب‌دار، اندازه هر موجودیت را به طور چشمگیری کاهش می‌دهد. این رویکرد نشان می‌دهد که با شناخت دقیق از داده‌ها و الگوهای دسترسی، می‌توان طراحی‌های بسیار کارآمدتری ایجاد کرد.در نهایت، نتایج به‌دست‌آمده در کامپایلر زیگ یعنی کاهش ۹۲ درصدی اندازه توکن‌ها و بهبود ۳۹ درصدی زمان اجرا، نشان می‌دهد که این تکنیک‌ها در دنیای واقعی و در پروژه‌های بزرگ به خوبی عمل می‌کنند.ارتباط با مباحث درسی معماری نرم‌افزاراین سخنرانی ارتباط عمیقی با مباحث درسی معماری نرم‌افزار و سیستم‌های کامپیوتری دارد. اولین ارتباط، معماری حافظه و سلسله‌مراتب حافظه نهان است. درک این که دسترسی به حافظه اصلی چندین مرتبه کندتر از محاسبات ریاضی است، یکی از مفاهیم کلیدی در طراحی سیستم‌های با کارایی بالا محسوب می‌شود. این موضوع در درس‌های معماری کامپیوتر و سیستم‌های عامل به تفصیل بررسی می‌شود.ارتباط دوم، الگوهای طراحی داده‌محور است. این رویکرد با الگوی سنتی شیءگرا که بر رفتار و کپسوله‌سازی تأکید دارد، تفاوت اساسی دارد. طراحی داده‌محور بر سازماندهی داده‌ها بر اساس الگوهای دسترسی و ویژگی‌های سخت‌افزاری تمرکز می‌کند.ارتباط سوم، مدیریت حافظه و تخصیص است. استفاده از آرایه‌های سازنده و شاخص‌ها به جای اشاره‌گرها، تأثیر مستقیمی بر نحوه تخصیص و دسترسی به حافظه دارد.ارتباط چهارم، تعادل بین قابلیت نگهداری و عملکرد است. رویکرد کدگذاری که در کامپایلر زیگ استفاده شده، قابلیت نگهداری کد را تا حدی کاهش می‌دهد اما عملکرد را به طور چشمگیری بهبود می‌بخشد. این مصالحه، یکی از چالش‌های اصلی در معماری نرم‌افزار به شمار می‌رود.نکات انتقادی و سوالات ایجاد شدهبا وجود موفقیت‌های چشمگیر، چند سوال و نکته انتقادی برای من ایجاد شد. سوال اول این است که رویکرد کدگذاری که اندازه گره‌ها را به شدت کاهش می‌دهد، چقدر بر قابلیت نگهداری و خوانایی کد تأثیر می‌گذارد؟ آیا این رویکرد برای تیم‌های بزرگ که نیاز به همکاری دارند، مناسب است؟ سخنران اشاره کرد که کدگذاری‌ها بر اساس توزیع‌های واقعی داده‌ها طراحی می‌شوند، اما تغییر این کدگذاری‌ها در آینده چقدر دشوار خواهد بود؟سوال دوم اینکه آیا این تکنیک‌ها برای همه نوع برنامه‌ها قابل تعمیم هستند؟ به نظر می‌رسد این رویکرد بیشتر برای سیستم‌هایی که تعداد زیادی شیء از یک نوع دارند و الگوهای دسترسی مشخصی دارند، مناسب است. برای برنامه‌هایی با ساختار داده‌های پیچیده و پویا، آیا این تکنیک‌ها همچنان مؤثر خواهند بود؟سوال سوم اینکه هزینه پیاده‌سازی این بهینه‌سازی‌ها چقدر است؟ سخنران اشاره کرد که کامپایلر زیگ هنوز در حال انتقال به کد جدید است و تنها ۳۵ درصد از تست‌های رفتاری را پاس می‌کند. آیا این بهینه‌سازی‌ها ارزش هزینه پیاده‌سازی و نگهداری را دارند؟ این موضوع به مبحث بازگشت سرمایه در بهینه‌سازی نرم‌افزار مربوط می‌شود.همچنین، هرچند طراحی داده‌محور مزایای عملکردی چشمگیری دارد، اما این رویکرد بدون محدودیت نیست. پیچیدگی کد، کاهش خوانایی، و دشواری نگهداری در بلندمدت، از جمله چالش‌های این رویکرد هستند. به‌ویژه در تیم‌های بزرگ که توسعه‌دهندگان مختلف روی کد کار می‌کنند، هزینه‌های نگهداری ممکن است از مزایای عملکردی بیشتر شود. بنابراین، انتخاب بین طراحی داده‌محور و شیءگرا باید بر اساس نیازمندی‌های خاص هر پروژه انجام شود.جمع‌بندی شخصیاین سخنرانی یکی از بهترین ارائه‌هایی بود که در زمینه بهینه‌سازی عملکرد دیده‌ام. اندرو کلی با زبانی ساده و مثال‌های عملی، مفاهیم پیچیده طراحی داده‌محور را به خوبی توضیح داده است. مهم‌ترین درسی که از این سخنرانی گرفتم، این است که درک عمیق از سخت‌افزار و نحوه عملکرد حافظه، می‌تواند به بهبودهای شگفت‌انگیزی در عملکرد نرم‌افزار منجر شود. حتی در پروژه‌های بزرگ و پیچیده مانند کامپایلر زیگ، با اعمال تکنیک‌های ساده طراحی داده‌محور، می‌توان به بهبودهای چشمگیری دست یافت. همچنین، این سخنرانی اهمیت سنجش و اندازه‌گیری در بهینه‌سازی را به من یادآوری کرد. سخنران با جمع‌آوری آمار دقیق و ارائه اعداد ملموس، تأثیر هر تغییر را نشان داد. این رویکرد مبتنی بر داده، یکی از اصول کلیدی مهندسی نرم‌افزار است که در تمام پروژه‌های موفق باید رعایت شود.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. منابع- Kelley, A. (n.d.). Data-Oriented Design in Practice. Zig Software Foundation. Retrieved from https://youtu.be/IroPQ150F6c?si=f9EH5p-AalCJeQOy- Fabian, R. (n.d.). Data-Oriented Design.مهسا دباغیانمهسا دباغیانThu, 09 Jul 2026 14:06:31 +0330https://virgool.ir/@m_17421119/spacetimedb-inverting-the-backend-why-we-built-our-mmorpg-inside-a-database-jwthx8z4xj3uعنوان سخنرانی: Inverting the Backend: Why We Built our MMORPG Inside a Databaseکنفرانس: Carnegie Mellon University Database Group - PostgreSQL vs. The Worldسخنران: Tyler Cloutier (CEO و هم‌بنیان‌گذار Clockwork Labs)تاریخ ارائه: ۶ آوریل ۲۰۲۶لینک ویدیو: https://youtu.be/-GhNDYCchqc?si=0j3y0gmqAEyl-Q_Uخلاصه فنیTyler Cloutier، مدیرعامل و یکی از بنیانگذاران Clockwork Labs، در این سخنرانی در دانشگاه کارنگی ملون، داستان ساخت یک بازی MMORPG به نام Bitcraft را روایت می‌کند که در دل یک پایگاه داده رابطه‌ای به نام SpacetimeDB قرار گرفته است.Bitcraftمعماری سنتی بازی‌های آنلاین از سه لایه : کلاینت، سرور بازی، و پایگاه داده تشکیل شده است سرور بازی منطق را اجرا می‌کند، وضعیت موقت را مدیریت می‌کند و با پایگاه داده برای ماندگاری ارتباط برقرار می‌کند. این جدایی باعث ایجاد مشکلاتی مانند عدم تطابق وضعیت، پیچیدگی هماهنگی و سربار شبکه می‌شود.SpacetimeDB این معماری را وارونه می‌کند. در این رویکرد، کلاینت مستقیماً به پایگاه داده متصل می‌شود و سرور بازی به عنوان کد رویه‌ای درون پایگاه داده اجرا می‌شود. منطق بازی به صورت ماژول‌های WebAssembly یا JavaScript در پایگاه داده بارگذاری می‌شود و تمام تراکنش‌ها به صورت اتمیک و با قوام ACID اجرا می‌شوند.ویژگی‌های کلیدی SpacetimeDB عبارتند از:کاهنده‌ها-Reducers: رویه‌های ذخیره‌شده با قابلیت اجرای اتمیک و قطعی که منطق بازی را پیاده‌سازی می‌کنند.اشتراک‌های پرس‌وجو: امکان دریافت به‌روزرسانی‌های بلادرنگ نتایج کوئری‌ها به صورت خودکار را می‌دهد.مدیریت طرحواره یکپارچه: کد و طرحواره هم‌زمان نسخه‌بندی می‌شوند و از ناهماهنگی جلوگیری می‌شود.احراز هویت OpenID Connect: امنیت اتصال مستقیم کلاینت به پایگاه داده را تضمین می‌کند.قابلیت به‌روزرسانی داغ: امکان تغییر کد سرور بدون قطع ارتباط کلاینت‌ها را می‌دهد.معماری داخلی SpacetimeDB:پایگاه داده درون‌حافظه با گزارش کامیت و عکس‌های دوره‌ایتکثیر داده‌ها از طریق OmniPaxosمسیریابی درخواست‌ها توسط یک پایگاه داده کنترل مرکزی که جدول مسیریابی را نگهداری می‌کندمدل هم‌روندی تک‌رشته‌ای با یک قفل بزرگ (که برای بسیاری از بازی‌ها عملکرد کافی دارد)مقیاس‌پذیری از طریق چندین مکانیسم:خواندن از کپی‌هاجداول توزیع‌شده برای داده‌های با تأخیر بالاپارتیشن‌بندی داده‌ها بر اساس کلیدارتباط بین پایگاه‌داده‌ای با قابلیت تضمین پردازش دقیقاً یک‌بارقابلیت اجرای کد روی کلاینت برای پیش‌بینی و کاهش تأخیر شبکهبرداشت شخصینکات جدید و جالب برای مناین سخنرانی برای من بسیار جذاب بود و چندین نکته جدید و شگفت‌انگیز داشت.اولین و مهم‌ترین نکته، مفهوم وارونگی باطن بود. این ایده که سرور بازی به طور کامل در پایگاه داده جاسازی شود و کلاینت مستقیماً با پایگاه داده ارتباط برقرار کند، کاملاً با معماری‌های سنتی که من با آنها آشنا بودم تفاوت دارد. این رویکرد بسیاری از مشکلات رایج در سیستم‌های توزیع‌شده مانند عدم تطابق وضعیت و سربار سریال‌سازی را حل می‌کند.دومین نکته جالب، استفاده از WebAssembly برای اجرای منطق سرور در پایگاه داده بود. این رویکرد به توسعه‌دهندگان اجازه می‌دهد از زبان‌های برنامه‌نویسی معمولی مانند Rust، C# و TypeScript استفاده کنند و از محدودیت‌های زبان‌های خاص رویه‌های ذخیره‌شده مانند PL/pgSQL فرار کنند. این یک پیشرفت بزرگ در تجربه توسعه‌دهندگی است.سومین نکته، اشتراک‌های پرس‌وجو بود. این قابلیت که کلاینت‌ها می‌توانند روی نتایج یک کوئری SQL مشترک شوند و به‌روزرسانی‌های بلادرنگ دریافت کنند، بسیار قدرتمند است. محاسبه افزایشی دلتاهای پرس‌وجو با استفاده از داده‌های تغییر یافته و موتور پرس‌وجوی تفاضلی، یک راه‌حل کارآمد برای پخش بلادرنگ وضعیت در بازی‌های آنلاین است.چهارمین نکته، به‌روزرسانی داغ ماژول بود. توانایی تغییر کد سرور در حال اجرا بدون قطع ارتباط کلاینت‌ها، یک ویژگی شگفت‌انگیز است که در معماری‌های سنتی بسیار دشوار است. تظاهر فیزیک برخورد دایره‌ها که در دمو نشان داده شد، این قابلیت را به خوبی به تصویر کشید.و در نهایت، اعتراف Tyler Cloutier در پایان سخنرانی که SpacetimeDB در واقع بیشتر یک سیستم‌عامل توزیع‌شده است تا یک پایگاه داده، بسیار جالب بود. این دیدگاه که نسل بعدی سیستم‌عامل‌ها باید پایگاه‌داده‌های توزیع‌شده را در دل خود داشته باشند، یک ایده بلندپروازانه و تحریک‌کننده است.ارتباط با مباحث درسی معماری نرم‌افزاراین سخنرانی ارتباط عمیقی با مباحث درسی معماری نرم‌افزار و پایگاه‌داده دارد.ارتباط اول: معماری سنتی سه‌لایه یک الگوی رایج است که در بسیاری از سیستم‌ها استفاده می‌شود. SpacetimeDB این الگو را با ادغام لایه‌های سرور و پایگاه داده به چالش می‌کشد و مزایا و معایب این رویکرد را نشان می‌دهد.ارتباط دوم: استفاده از یک قفل بزرگ و مدل تک‌رشته‌ای در SpacetimeDB، یادآور بحث‌های کلاسیک در مورد هم‌روندی در پایگاه‌داده‌ها است. این رویکرد سادگی و عملکرد بالا را در ازای از دست دادن مقیاس‌پذیری افقی ارائه می‌دهد، که نشان‌دهنده مصالحه‌های اساسی در طراحی سیستم‌های توزیع‌شده است.ارتباط سوم: رویکرد SpacetimeDB در تعریف طرحواره به عنوان بخشی از کد، مشابه ORM‌ها است، اما با این تفاوت که هم‌زمانی و یکپارچگی بیشتری را فراهم می‌کند. این موضوع به مبحث مدیریت نسخه و مهاجرت‌های پایگاه‌داده در درس معماری نرم‌افزار مربوط می‌شود.ارتباط چهارم: مدل بازیگر است. قابلیت ارسال پیام بین پایگاه‌داده‌ها در SpacetimeDB شباهت زیادی به مدل بازیگر در سیستم‌هایی مانند Akka و Erlang دارد و نشان‌دهنده تأثیر این الگو بر طراحی سیستم‌های مدرن است.ارتباط پنجم: بهینه‌سازی عملکرد است. استفاده از پایگاه‌داده درون‌حافظه، گزارش کامیت، عکس‌های دوره‌ای، و محاسبه افزایشی دلتاها، همگی تکنیک‌هایی هستند که در درس‌های پایگاه‌داده و سیستم‌های توزیع‌شده بررسی می‌شوند.نکات انتقادی و سوالات ایجاد شدهبا وجود نوآوری‌های چشمگیر، چند سوال و نکته انتقادی برای من ایجاد شد:سوال اول: مدل تک‌رشته‌ای با قفل بزرگ، چقدر مقیاس‌پذیر است؟ سخنران اشاره کرد که برای بازی‌های MMO با چند گیگابایت داده، این مدل عملکرد خوبی دارد و تأخیر تراکنش‌ها زیر میلی‌ثانیه است. اما برای برنامه‌هایی با حجم داده بسیار بالا یا نرخ تراکنش خیلی زیاد، آیا این مدل به گلوگاه تبدیل نمی‌شود؟ راه‌کارهای پارتیشن‌بندی و جداول توزیع‌شده که مطرح شد، چقدر عملی هستند؟سوال دوم: اتصال مستقیم کلاینت به پایگاه‌داده چه پیامدهای امنیتی دارد؟ اگرچه SpacetimeDB از احراز هویت OpenID Connect و مجوزهای مبتنی بر نما استفاده می‌کند، اما آیا این رویکرد به اندازه معماری سنتی با لایه سرور میانی امن است؟ آیا حملاتی مانند تزریق کوئری یا دسترسی غیرمجاز به داده‌ها در این مدل ساده‌تر نیستند؟سوال سوم: قابلیت به‌روزرسانی داغ ماژول در حین اجرا، چه محدودیت‌هایی دارد؟ آیا هر تغییری در کد را می‌توان بدون قطع ارتباط اعمال کرد؟ اگر تغییری نیاز به تغییر ساختار داده داشته باشد، چه اتفاقی می‌افتد؟ مهاجرت‌های دستی که در حال توسعه هستند، چقدر پیچیده خواهند بود؟نکته انتقادی: سخنرانی به شدت بر روی بازی‌های MMO متمرکز است و ادعا می‌کند که این رویکرد برای هر برنامه‌ای که نیاز به وضعیت تغییرپذیر بلادرنگ دارد، مفید است. اما من کنجکاوم که آیا SpacetimeDB برای برنامه‌های با تراکنش‌های تحلیلی پیچیده یا برنامه‌های با نیازهای گزارش‌گیری سنگین نیز مناسب است؟جمع‌بندی شخصیاین سخنرانی یکی از جذاب‌ترین ارائه‌هایی بود که در زمینه معماری نرم‌افزار دیده‌ام. SpacetimeDB با وارونه کردن معماری سنتی، نشان می‌دهد که چگونه بازنگری در مفروضات اساسی می‌تواند به راه‌حل‌های نوآورانه منجر شود. این پروژه جسورانه، اگرچه ممکن است برای همه موارد مناسب نباشد، اما پتانسیل بالایی برای ساده‌سازی توسعه برنامه‌های بلادرنگ و کاهش پیچیدگی سیستم‌های توزیع‌شده دارد.مهم‌ترین درسی که از این سخنرانی گرفتم، این است که گاهی بهترین راه‌حل برای یک مشکل، ادغام اجزا به جای جداسازی آنهاست. جداسازی نگرانی‌ها یک اصل مهم در معماری نرم‌افزار است، اما این سخنرانی نشان می‌دهد که گاهی ادغام هوشمندانه می‌تواند مزایای قابل‌توجهی از نظر عملکرد، سادگی و کارایی ارائه دهد. تعادل بین این دو رویکرد، هنر معماری نرم‌افزار است.همچنین، این سخنرانی اهمیت درک عمیق از نیازمندی‌های برنامه و طراحی راه‌حل‌های متناسب با آن را نشان می‌دهد. Clockwork Labs به جای استفاده از ابزارهای موجود و پذیرش محدودیت‌های آنها، تصمیم به ساخت ابزار مورد نیاز خود گرفت. این رویکرد، اگرچه پرریسک است، اما می‌تواند به مزیت رقابتی قابل‌توجهی منجر شود.«اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است»منابعCloutier, T. (2026). SpacetimeDB → Inverting the Backend: Why We Built our MMORPG Inside a Database. Carnegie Mellon University Database Group. Retrieved from https://youtu.be/-GhNDYCchqc?si=0j3y0gmqAEyl-Q_USpacetimeDB Documentation. (n.d.). SpacetimeDB - The Database for Real-Time Applications. Retrieved from https://spacetimedb.com/مهسا دباغیانمهسا دباغیانThu, 09 Jul 2026 13:19:55 +0330https://virgool.ir/@m_17421119/مهاجرت-league-of-legends-به-aws-wfiq4tiba2l9عنوان سخنرانی: Effortless game launches: How League of Legends runs at scale on AWSکنفرانس: AWS re:Invent 2024سخنرانان:Ashwin Raghuraman (Senior Solutions Architect @AWS)Brian Miller (Engineering Manager @Riot Games)David Press (Principal Engineer @Riot Games)لینک ویدیو: https://www.youtube.com/watch?v=1Sgft5IeC-Eخلاصه فنیاین سخنرانی، روایتی جامع از مهاجرت بازی‌های افسانه‌ای League of Legends و تاکتیک‌های مبارزه تیمی -TFT از زیرساخت‌های فلزی محلی به فضای ابری AWS ارائه می‌دهد.معماری بازی‌های Riot از دو بخش اصلی تشکیل شده است: سرورهای پلتفرم که خدمات خارج از بازی مانند احراز هویت، فروشگاه، همسریابی و سیستم‌های پیشرفت را با استفاده از سرویس‌های وب استاندارد جاوا ارائه می‌دهند، و سرورهای بازی که تجربه درون بازی با تأخیر پایین را با استفاده از بسته‌های UDP مدیریت می‌کنند. سرورهای بازی به دلیل نیاز به تأخیر کم، اجرای شبیه‌سازی در ۳۰ فریم بر ثانیه و قابلیت آدرس‌دهی مستقل، الزامات تخصصی دارند.رایِت گیمز یک توسعه‌دهنده بازی، ناشر بازی ویدئویی و برگزارکننده مسابقات ورزش الکترونیکی است که در سال ۲۰۰۶ تأسیس شد.چالش‌های اصلی معماری قبلی شامل موارد زیر بود:مشکل مقیاس‌پذیری: نیاز به خرید ظرفیت اضافی برای پیش‌بینی‌های ناقص که منجر به اتلاف هزینه می‌شد.محدودیت‌های راهکار DDoS: تنها از ۲۵۵ بازی در هر میزبان و دو نسخه هم‌زمان بازی پشتیبانی می‌کرد.هزینه‌های سنگین مجوز ویندوز: نیاز به استفاده از نمونه‌های اختصاصی EC2 بوده‌است.مدیریت ناوگان عظیم ویندوزی: به دلیل از دست رفتن تخصص، به مشکل بزرگی تبدیل شده بود.موفقیت بازی Valorant که با معماری ابری-اول روی سرورهای لینوکس و کانتینرها راه‌اندازی شد، انگیزه‌ای برای مهاجرت لیگ آو لجندز ایجاد کرد. این مهاجرت شامل سه مرحله اصلی بود:۱. انتقال از مراکز داده محلی به AWS: آخرین مرکز داده در استانبول به پایگاه AWS منتقل شد.۲. مهاجرت سرورهای بازی از ویندوز به لینوکس: شامل بازنویسی فرضیات مبتنی بر APIهای ویندوز، تست عملکرد و رفع باگ‌های پلتفرمی مانند مشکل ظروف نامرتب در C++ بود.۳. پیاده‌سازی مقیاس‌بندی خودکار.برای مقیاس‌بندی خودکار سرورهای بازی، تیم Riot با چالش پروفایل‌های عملکردی متغیر مواجه شد. برخلاف Valorant که عملکردی ثابت در طول مسابقه دارد، لیگ آو لجندز با توزیع دمی بلند از مدت زمان بازی‌ها و افزایش مصرف CPU در اواسط تا انتهای بازی مشخص می‌شود. TFT نیز رفتار متفاوتی دارد و مصرف CPU در انتهای بازی کاهش می‌یابد.تیم Riot با استفاده از شبیه‌سازی بر اساس داده‌های واقعی، الگوریتم‌های مختلف متعادل‌سازی بار را آزمایش کرد و در نهایت الگوریتم Round Robin را انتخاب کرد که واریانس مصرف CPU را به طور قابل‌توجهی کاهش داد و امکان افزایش آستانه مقیاس‌گذاری از ۴۰٪ به حدود ۶۰٪ را فراهم کرد. این بهبود به تنهایی منجر به صرفه‌جویی سالانه تا ۱۰ میلیون دلار شد.بازی Valorantپس از مهاجرت، Riot توانست حالت‌های بازی جدید مانند Swarm با پروفایل عملکردی متفاوت و چهار بازیکن و حالت جدید TFT با محدودیت حافظه به جای CPU را به سرعت راه‌اندازی کند و پس از اتمام، منابع را مجدداً کاهش دهد. همچنین پلتفرم تأمین بازی (GPP) که بر اساس معماری Valorant ساخته شده بود، به عنوان یک سرویس مشترک برای بازی‌های مختلف Riot در دسترس قرار گرفت و حتی در هکاتون Thunderdome، مهندسان توانستند لیگ را روی نمونه‌های Graviton با هزینه پایین اجرا کنند.برداشت شخصینکات جدید و جالب برای منچندین نکته در این ارائه برای من بسیار جذاب و جدید بود. اولین نکته، چالش‌های خاص سرورهای بازی مانند نیاز به آدرس‌دهی مستقل هر سرور و آسیب‌پذیری در برابر حملات DDoS بود که آن را از سرویس‌های وب معمولی متمایز می‌کند. همچنین الگوریتم Round Robin برای متعادل‌سازی بار سرورهای بازی و نحوه استفاده از شبیه‌سازی برای یافتن بهترین الگوریتم، بسیار جالب بود.نکته جالب دیگر، تفاوت رفتار عملکردی بازی‌های مختلف بود. League of Legends با افزایش مصرف CPU در انتهای بازی، TFT با کاهش مصرف در انتها، و Valorant با عملکرد ثابت در طول مسابقه، هر کدام نیازمند استراتژی متفاوتی برای بسته‌بندی بازی‌ها روی میزبان‌ها هستند.همچنین مهاجرت سرورهای بازی ۱۵ ساله از ویندوز به لینوکس و باگ‌های پلتفرمی مانند تفاوت رفتار ظروف نامرتب در C++ بین دو سیستم‌عامل، نشان‌دهنده پیچیدگی‌های مهاجرت سیستم‌های قدیمی است.League of Legendsارتباط با مباحث درسی معماری نرم‌افزارارتباط اول: الگوهای مهاجرت است. Riot از الگوی خفه‌کننده-Strangler برای مهاجرت تدریجی استفاده کرد و ابتدا سرورهای پلتفرم و سپس سرورهای بازی را به صورت منطقه‌به‌منطقه منتقل نمود.ارتباط دوم: مقیاس‌پذیری و کشش الاستیک است. Riot با استفاده از مقیاس‌بندی خودکار EC2، توانست حالت‌های بازی موقت مانند Swarm را با سه برابر ظرفیت معمول راه‌اندازی کند و پس از پایان، منابع را کاهش دهد. این همان مفهوم کشسانی-Elasticity در محاسبات ابری است که در درس‌های معماری نرم‌افزار مطرح می‌شود.ارتباط سوم: بهینه‌سازی عملکرد است. استفاده از شبیه‌سازی برای یافتن بهترین الگوریتم متعادل‌سازی بار و کاهش واریانس مصرف CPU، نمونه‌ای از بهینه‌سازی عملکرد در سطح زیرساخت است. صرفه‌جویی ۱۰ میلیون دلاری سالانه نشان‌دهنده اهمیت این بهینه‌سازی‌هاست.ارتباط چهارم: مدیریت تغییر و ریسک است. مهاجرت تدریجی، برنامه بازگشت به حالت قبل، و نظارت مستمر بر عملکرد، همگی نشان‌دهنده رویکرد محافظه‌کارانه و مبتنی بر ریسک Riot در مدیریت تغییر است.نکات انتقادی و سوالات ایجاد شدهچند سوال و نکته انتقادی برای من ایجاد شد:سوال اول: آیا الگوریتم Round Robin برای همه مناطق و با ترکیب قهرمانی مختلف که رفتار عملکردی متفاوتی دارند، به یک اندازه کارایی دارد؟ ارائه اشاره کرد که مناطق مختلف رفتار متفاوتی دارند، اما مشخص نکرد که آیا الگوریتم انتخاب‌شده برای همه مناطق بهینه است یا صرفاً یک میانگین قابل قبول ارائه می‌دهد.سوال دوم: Riot چگونه تشخیص می‌دهد که یک میزبان خاص به آستانه ۸۰٪ CPU رسیده است و چه مکانیسمی برای جلوگیری از فراتر رفتن از این آستانه وجود دارد؟ با توجه به اینکه بازی‌ها به تدریج گران‌تر می‌شوند، پیش‌بینی این که آیا میزبان در آینده از آستانه عبور خواهد کرد یا خیر، چالش‌برانگیز به نظر می‌رسد.نکته انتقادی: مهاجرت از ویندوز به لینوکس با وجود صرفه‌جویی در هزینه مجوز، پیچیدگی‌های زیادی داشت که می‌توانست از طریق رویکردهای تدریجی‌تر مانند اجرای ترکیبی کاهش یابد. باگ ظروف نامرتب که پس از انتشار زنده شناسایی شد، نشان‌دهنده نیاز به تست‌های گسترده‌تر در محیط‌های پیش‌تولید است.سوال سوم: آیا پلتفرم GPP برای بازی‌های جدیدی که از موتورهای متفاوت (غیر از Unreal) استفاده می‌کنند، قابل استفاده است یا نیاز به سفارشی‌سازی دارد؟ ارائه اشاره کرد که بازی‌های R&D از GPP استفاده کرده‌اند، اما مشخص نیست که آیا این پلتفرم برای موتورهای سفارشی نیز به همین راحتی قابل تطبیق است یا خیر.جمع‌بندی شخصیاین ارائه برای من بسیار جذاب بود و نشان داد که مهاجرت سیستم‌های بزرگ و قدیمی به ابر، با وجود چالش‌های فراوان، کاملاً شدنی است و می‌تواند مزایای قابل‌توجهی از جمله کاهش هزینه، افزایش چابکی و امکان آزمایش حالت‌های جدید بازی را به همراه داشته باشد.مهم‌ترین درسی که گرفتم، اهمیت اندازه‌گیری و شبیه‌سازی قبل از پیاده‌سازی تغییرات بزرگ است. Riot با استفاده از داده‌های واقعی و شبیه‌سازی، توانست بهترین الگوریتم را انتخاب کند و ریسک مهاجرت را کاهش دهد. همچنین همکاری نزدیک با تیم AWS و استفاده از سرویس‌های مدیریت‌شده، نشان‌دهنده اهمیت شراکت استراتژیک در سفر ابری است.«اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است»منابعAWS re:Invent 2024. (2024). Effortless game launches: How League of Legends runs at scale on AWS. Retrieved from https://www.youtube.com/watch?v=1Sgft5IeC-ERiot Games Technology Blog. (n.d.). Running Online Services at Riot. Retrieved from https://technology.riotgames.com/مهسا دباغیانمهسا دباغیانThu, 09 Jul 2026 13:04:48 +0330https://virgool.ir/@m_17421119/مرور-سخنرانی-داستان-تکامل-معماری-pubg-در-aws-vroh1ghnybjvعنوان سخنرانی: The Evolution Story of Game Architecture: PUBG: Battlegrounds, KRAFTONسخنران: Jung Hun Kim (DevOps Team Lead @KRAFTON) و همکاران از AWSکنفرانس: AWS re : Invent 2024لینک ویدیو: https://www.youtube.com/watch?v=GhYUjTxSOkEخلاصه فنیسخنرانی Jung Hun Kim از شرکت KRAFTON، روایتی جامع از سفر مدرنیزاسیون یکی از محبوب‌ترین بازی‌های چندنفره آنلاین جهان، یعنی PUBG: Battlegrounds، ارائه می‌دهد. این بازی با رکورد ۳.۲۵ میلیون بازیکن هم‌زمان در پلتفرم STEAM، همواره با چالش‌های جدی در زمینه مقیاس‌پذیری، کارایی و چابکی عملیاتی مواجه بوده است.معماری PUBG از دو بخش اصلی تشکیل شده است: سرور لابی که مسئولیت خدمات خارج از بازی مانند احراز هویت، تطبیق بازیکنان و جدول امتیازات را بر عهده دارد، و سرور جلسه که وضعیت بازیکنان را در طول بازی پردازش می‌کند. سرور لابی در ابتدا روی گروه‌های مقیاس‌بندی خودکار EC2 مبتنی بر ویندوز اجرا می‌شد و تیم توسعه با چالش‌هایی مانند ناکارآمدی، کاهش بهره‌وری و چابکی عملیاتی محدود دست و پنجه نرم می‌کرد.PUBG: Battlegroundsکرافتون، مدرنیزاسیون را در نوامبر ۲۰۱۸ از محیط تضمین کیفیت آغاز کرد و در اکتبر ۲۰۱۹، محیط تولید سرور لابی به طور کامل به کانتینرها و سرویس EKS منتقل شد. در ژوئیه ۲۰۲۱، نوبت به سرورهای جلسه رسید که با استفاده از Agones – یک راهکار متن‌باز برای مدیریت سرورهای بازی در کوبرنتیز – به این مهاجرت پیوستند.برای مدیریت محیط‌های متعدد QA، کرافتون از کانتینرها و کوبرنتیز استفاده کرد و منابع را به دو گروه اختصاصی و مشترک تقسیم نمود. منابع اختصاصی مانند صف‌های SQS و جداول DynamoDB برای هر محیط به صورت جداگانه ایجاد می‌شدند، در حالی که منابع محاسباتی و شبکه‌ای مانند VPCها بین محیط‌ها به اشتراک گذاشته می‌شدند تا هزینه‌ها کاهش یابد.برای مهاجرت تولید، کرافتون رویکرد ترکیبی را در پیش گرفت؛ منابع پایدار مانند خوشه‌های EKS با Terraform مدیریت می‌شدند، در حالی که استقرار سرورها به صورت پویا در کوبرنتیز انجام می‌گرفت. آنها برای کنترل ترافیک، از VPC CNI استفاده کردند تا غلاف‌های کوبرنتیز بتوانند مستقیماً با نمونه‌های EC2 ارتباط برقرار کنند. با این حال، پس از مهاجرت با چالش توزیع ناهموار ترافیک مواجه شدند و برای حل این مشکل، از Istio به عنوان شبکه سرویس جدید خود بهره بردند که مدیریت ترافیک و مسیریابی پیشرفته‌تری را فراهم می‌کرد.یکی از چالش‌های مهم، تأخیر بالای بوت‌استرپ سرورهای جلسه بود که تا ۱۵ دقیقه طول می‌کشید. کرافتون با راه‌اندازی Harbor و CloudFront به عنوان پروکسی کش تصاویر، و ایجاد پاد ImagePuller به صورت DaemonSet، این زمان را به زیر ۴ دقیقه کاهش داد.در زمینه بهینه‌سازی هزینه، کرافتون با مهاجرت به نمونه‌های Graviton مبتنی بر معماری ARM، به بهبود ۳۵ درصدی نسبت عملکرد به قیمت دست یافت، بدون آنکه پایداری تأخیر به خطر بیفتد. آنها با بهینه‌سازی فرآیند مدیریت تصاویر و تولید مانیفست تصویربرداری، توانستند به طور هم‌زمان از هر دو معماری ARM و X86 پشتیبانی کنند.درس‌های کلیدی این مهاجرت شامل تمرکز بر کارهای ارزشمند و حذف کارهای غیرضروری با استفاده از سرویس‌های مدیریت‌شده، آگاهی از عوارض جانبی غیرمنتظره مهاجرت، و همیشه داشتن برنامه بازگشت به حالت قبل برای مدیریت مسائل غیرمنتظره است. همکاری نزدیک با تیم AWS و ارائه بازخورد به آنها، منجر به راه‌اندازی ویژگی HostPort برای سیستم‌های ویندوزی در EKS در کمتر از دو ماه شد.برداشت شخصینکات جدید و جالب برای منچندین نکته در این ارائه برای من بسیار جذاب و جدید بود. اولین و مهم‌ترین مورد، استفاده از Agones برای مدیریت سرورهای جلسه بازی بود. تا قبل از این، تصور می‌کردم که کوبرنتیز برای مدیریت تمام انواع workloadها به یک شکل عمل می‌کند، اما با Agones متوجه شدم که سرورهای جلسه بازی نیازمندی‌های خاصی دارند که با پادهای معمولی تفاوت اساسی دارد. ویژگی‌هایی مانند مدیریت چرخه حیات Game Server، تخصیص مبتنی بر انتخابگر، و به‌روزرسانی مداوم مشابه استقرارهای کوبرنتیز، نشان می‌دهد که چگونه یک راهکار متن‌باز می‌تواند نیازهای خاص یک صنعت را به خوبی پوشش دهد.دومین نکته جالب، مهاجرت به نمونه‌های Graviton مبتنی بر معماری ARM بود. همیشه فکر می‌کردم که تغییر معماری پردازنده، کاری بسیار دشوار و زمان‌بر است، اما کرافتون نشان داد که با برنامه‌ریزی مناسب و بهینه‌سازی ابزارهای ساخت، این کار شدنی است. نکته جالب‌تر اینکه آنها با این مهاجرت به بهبود ۳۵ درصدی نسبت عملکرد به قیمت دست یافتند و متوجه شدند که معماری ARM در برابر نوسانات پردازنده مقاوم‌تر است و تأخیر پایدارتری ارائه می‌دهد. این موضوع نشان می‌دهد که انتخاب معماری پردازنده چقدر می‌تواند بر عملکرد نهایی تأثیر بگذارد.سومین نکته، استفاده از Istio به عنوان شبکه سرویس برای حل مشکل توزیع ناهموار ترافیک بود. داستان جالب اینجاست که کشف سرویس مبتنی بر etcd که خودشان طراحی کرده بودند، به خوبی کار می‌کرد، اما پس از مهاجرت به کوبرنتیز و استفاده از سرویس Kubernetes، با چالش توزیع ترافیک مواجه شدند. این نشان می‌دهد که گاهی راه‌حل‌های سفارشی که برای یک معماری خاص طراحی شده‌اند، نمی‌توانند به سادگی به معماری جدید منتقل شوند و نیاز به بازنگری اساسی دارند.ارتباط با مباحث درسی معماری نرم‌افزاراین سفر مدرنیزاسیون، ارتباط عمیقی با مباحث درسی معماری نرم‌افزار دارد. اولین ارتباط، الگوهای طراحی است. کرافتون از الگوی Strangler برای مهاجرت تدریجی استفاده کرد؛ آنها ابتدا محیط QA را به کانتینرها منتقل کردند، سپس محیط تولید، و حتی در محیط تولید، ترافیک را به تدریج بین نمونه‌های قدیمی و جدید تقسیم کردند تا اطمینان حاصل شود که مهاجرت با موفقیت انجام می‌شود. ارتباط دوم، مقیاس‌پذیری است. یکی از چالش‌های اصلی PUBG، مدیریت هم‌زمان صدها محیط QA بود که هر کدام نیاز به منابع جداگانه داشتند. با استفاده از کانتینرها و کوبرنتیز، آنها توانستند منابع را به اشتراک بگذارند و هزینه‌ها را به طور قابل‌توجهی کاهش دهند. این موضوع دقیقاً همان مفهومی است که در مباحث مقیاس‌پذیری عمودی و افقی در درس معماری نرم‌افزار مطرح می‌شود.ارتباط سوم، مدیریت ریسک در مهاجرت معماری است. کرافتون با داشتن برنامه بازگشت به حالت قبل Rollback Plan، توانست ریسک مهاجرت را مدیریت کند. همچنین آنها با انتقال تدریجی ترافیک و نظارت مستمر بر عملکرد، از بروز مشکلات جدی جلوگیری کردند. این رویکرد، مصداق عملی از مدیریت تغییر در معماری نرم‌افزار است.ارتباط چهارم، Separation of Concerns است. آنها با تفکیک سرور لابی و سرور جلسه، و همچنین تفکیک منابع اختصاصی و مشترک، توانستند هر بخش را به طور مستقل مدرنیزه کنند. این اصل، یکی از اصول پایه‌ای معماری نرم‌افزار است که در طراحی سیستم‌های بزرگ بسیار حیاتی است.نکات انتقادی و سوالات ایجاد شدهبا وجود موفقیت‌های چشمگیر، چند سوال و نکته انتقادی برای من ایجاد شد:سوال اول: آیا این رویکرد برای همه بازی‌های چندنفره آنلاین قابل‌تعمیم است؟ PUBG یک بازی بتل رویال با جلسات نسبتاً طولانی است. آیا برای بازی‌هایی با جلسات کوتاه‌تر و تعداد جلسات بسیار بیشتر مانند بازی‌های موبایلی نیز این رویکرد کارایی دارد؟ به نظر می‌رسد مدیریت تعداد بسیار بیشتری از Game Serverها در کوبرنتیز، چالش‌های جدیدی ایجاد کند که شاید در این ارائه به آنها اشاره نشده است.سوال دوم: آیا استفاده از Agones بهترین انتخاب بود یا راه‌حل‌های جایگزین مانند OpenKruise یا راه‌حل‌های اختصاصی نیز می‌توانستند موفق باشند؟ من کنجکاوم که کرافتون چه معیارهایی را برای انتخاب Agones در نظر گرفته است و آیا این انتخاب بر اساس بررسی گزینه‌های مختلف یا صرفاً به دلیل جامعه فعال آن بوده است ؟نکته انتقادی: یکی از چالش‌هایی که کرافتون با آن مواجه شد، تأخیر بوت‌استرپ اولیه سرورهای جلسه بود که تا ۱۵ دقیقه طول می‌کشید و آنها با استفاده از راه‌کارهایی مانند Harbor و ImagePuller آن را به زیر ۴ دقیقه کاهش دادند. با این حال، به نظر می‌رسد هنوز این زمان برای شرایط بحرانی مانند افزایش ناگهانی تعداد بازیکنان، نسبتاً بالاست. آیا راه‌کارهایی مانند پیش‌گرم کردن پادها-Pod Pre-warming یا استفاده از Serverless برای مدیریت ترافیک ناگهانی می‌توانستند مؤثرتر باشند؟سوال سوم: با توجه به اینکه سرور جلسه PUBG بر اساس موتور Unreal ساخته شده و این موتور به شدت به تأخیر و عملکرد پایدار حساس است، آیا کانتینری کردن سرور جلسه می‌تواند به تأخیر شبکه اضافه کند؟ از آنجایی که کانتینرها از Overlay Network استفاده می‌کنند، آیا این موضوع می‌تواند تأثیر منفی بر تجربه بازیکنان داشته باشد؟ کرافتون با استفاده از VPC CNI این مشکل را حل کرده اما من کنجکاوم که آیا در عمل این راه‌کار کاملاً مؤثر بوده است یا هنوز چالش‌هایی وجود دارد.جمع‌بندی شخصیاین ارائه برای من بسیار الهام‌بخش بود و نشان داد که حتی بزرگترین و پیچیده‌ترین سیستم‌ها نیز قابل مدرنیزه شدن هستند. مهم‌ترین درسی که گرفتم این است که مدرنیزاسیون فقط تغییر فناوری نیست، بلکه تغییر رویکرد، فرهنگ و فرآیندهاست. کرافتون با ترکیب سرویس‌های مدیریت‌شده AWS، ابزارهای متن‌باز، و فرهنگ یادگیری مستمر، توانسته است معماری PUBG را به سطح جدیدی از کارایی، مقیاس‌پذیری و چابکی برساند. همچنین همکاری نزدیک با تیم AWS و ارائه بازخورد به آنها، نمونۀ زیبایی از یک رابطه برد-برد است که هم به نفع مشتری و هم به نفع ارائه‌دهنده سرویس تمام می‌شود.«اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است»مهسا دباغیانمهسا دباغیانThu, 09 Jul 2026 12:46:24 +0330https://virgool.ir/@m_17421119/بیست-مفهومی-که-هر-معمار-نرم-افزاری-باید-بداند-lxgo4cmydfslمقدمه: دری به دنیای بی‌کراندر سیاه‌چالهٔ نرم‌افزار و معماری نرم‌افزار، هر عبارت می‌تواند دری به سوی دنیایی بی‌کران باز کند.گاهی یک واژه آنقدر عمیق است که ماه‌ها طول می‌کشد تا مفهوم آن را به صورت کامل لمس کنید.در این پست، قصد دارم شما را به سفری دعوت کنم که در هر ایستگاه یکی از بیست مفهوم رایج، در معماری نرم‌افزار بیان می‌شود.تمام تلاش من این بوده است که توضیحات، ساده و روان باشند، بدون اینکه از دقت و جزئیات علمی کم شود.در نهایت اگر پس از خواندن این نوشته، بهره‌وری علمی و عملی‌تان بیشتر شود، به هدفم رسیده‌ام . این نوشته حاصل جستجو در منابع معتبر علمی (مقالات علمی، مستندات ابزارهای متن‌باز، و وبلاگ‌های مهندسی شرکت‌های بزرگ) است.ایستگاه اول : Chaos Engineeringتزریق آشوب کنترل شدهمفهوم Chaos Engineeringنوشته‌ها و تجربه‌های منتشرشده از تیم‌های بزرگی مثل نتفلیکس نشان می‌دهد که تاب‌آوری یک سیستم توزیع‌شده هیچ‌وقت قابل پیش‌بینی نیست. زیرا تعداد حالات خرابی آنقدر زیاد است که هیچ تست سنتی نمی‌تواند همه آن‌ها را پوشش دهد.Chaos Engineering دقیقاً برای همین مسئله طراحی شده است: این مفهوم برخلاف تصور عموم، به معنای خرابکاری تصادفی نیست، بلکه یک روش علمی و دقیق است. در این رویکرد، ابتدا حالت پایدار سیستم تعریف می‌شود، سپس فرضیه‌ای مطرح می‌شود و پس از آن، خطای موردنظر به صورت کنترل‌شده با یک شعاع انفجار محدود، مانند واکسن تزریق می‌شود. در این آزمایش هدف نهایی فرض کردن تاب آوری نخواهد بود بلکه اثبات تاب‌آوری است.تفاوت مهندسی آشوب با تست سنتی در این است که اولی در محیط واقعی  به صورت مداوم اجرا می‌شود، دومی در محیط تست، به صورت نقطه‌ای انجام می‌شود.یک مرور ادبیات گسترده که ۸۸ منبع را بین ژانویه ۲۰۱۹ تا آوریل ۲۰۲۴ بررسی کرده، نشان می‌دهد که سازمان‌های متوسط و بزرگ بیشترین استفاده را از این روش دارند. ابزارهایی متن‌باز مثل Kubernetes امکان تعریف سناریوهای خرابی را به صورت Chaos-as-Code فراهم می‌کنند. سناریوهای کلاسیک شامل قطع ارتباط بین سرویس‌ها مانند پارتیشن‌بندی شبکه، حذف تصادفی Podها، و تزریق تأخیر در پاسخ پایگاه داده است. کی این روش مناسب نخواهد بود؟ اگر سیستم‌ شما آنقدر ساده است که همه حالت‌های خرابی آن را از قبل می‌شناسی، یا اگر مشتری‌های حقیقی‌ کسب و کار شما تحمل قطعی حتی یک درصد را ندارند Chaos Engineering  گزینه مناسبی برای شما، نخواهد بود.منابعOwotogbe, J., Kumara, I., Van Den Heuvel, W., & Tamburri, D. A. (2024). Chaos Engineering: A Multi-Vocal Literature Review. arXiv preprint arXiv:2412.01416.Chaos Mesh. (n.d.). Chaos Mesh documentation: A Chaos Engineering platform for Kubernetes. CNCF Incubating Project. Retrieved from https://chaos-mesh.orgایستگاه دوم : Backend for FrontendBackend vs Frontendمفهوم Backend for Frontendفرض کنید، کسب و کار شما  یک اپلیکیشن موبایل و یک نسخه وب دارد که هر دو از یک سرور یکسان داده دریافت می‌کنند. صفحه اصلی در موبایل فقط به سه فیلد از پاسخ نیاز دارد، در حالی که وب به پانزده فیلد نیازمند است. اگر هر دو از یک API واحد استفاده کنند، یکی از این دو یا داده اضافه می‌گیرد یا مجبور است چندین درخواست جداگانه بفرستد.الگوی Backend for Frontend دقیقاً همین مشکل را حل می‌کند. به جای یک API Gateway عمومی، برای هر کلاینت یک backend اختصاصی ساخته می‌شود.این الگو را سام نیومن، معمار مشهور، در کتاب و مقالاتش به تفصیل توضیح داده است.باید توجه داشت که یک BFF فقط حاوی منطق ارائه است و نباید منطق دامین را در خود جای دهد. تیمی که مسئول frontend است، مالکیت BFF متناظر را نیز بر عهده دارد و هر دو با هم و همزمان deploy می‌شوند. در معماری‌های پلی‌گلات،چندزبانه اهمیت BFF این الگو بیشتر هم می‌شود، زیرا می‌تواند تفاوت‌های فنی بین پلتفرم‌ها را پنهان کند. مثلاً BFF می‌تواند داده مخصوص IOS را به فرمتی تبدیل کند که کتابخانه‌های خاص این پلتفرم بهتر متوجه شوند.یک اشتباه متداول BFF و API Gateway گاهی با هم اشتباه می‌شوند. یک راه متداول این است که API Gateway را به عنوان دروازه ورودی درنظرگرفته که درخواست را به BFF مناسب مثلاً BFF موبایل یا BFF وب هدایت کند. یعنی API Gateway مسیریابی می‌کند، BFF منطق ارائه را اجرا می‌کند. باید در نظر داشت که این دو رقیب هم نیستند بلکه به یکدیگر کمک می‌کنند. البته اگر فقط یک کلاینت وجود داشته باشد، BFF اضافه است و نیازی به استفاده از آن نیست.عوارض استفاده این الگو چیست؟با این الگو تعداد سرویس‌ها افزایش می‌یابد و هزینه نگهداری و پیچیدگی افزایش می‌یابد. همچنین افزودن لایه منجر به تاخیر میشود. عوارض احتمالی دیگر تکرار کد است .منابعMicrosoft Architecture Center. (n.d.). Backend for Frontend (BFF) pattern. Retrieved from https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontendsMotia Framework. (n.d.). Motia documentation: Step-based BFF implementation. Retrieved from https://motia.dev Newman, S. (2019). Building Microservices (2nd ed.). O'Reilly Media.ایستگاه سوم : AI for Software Engineeringهوش مصنوعی در خدمت انسانمفهوم AI for Software Engineeringاحتمالاً این روزها شنیده‌اید که توسعه‌دهندگان با کمک هوش مصنوعی کد می‌نویسند. اما نکته قابل توجه این است که برخی سازمان‌ها بیش از ۴۵ درصد کدهای جدید خود را با کمک هوش مصنوعی تولید می‌کنند. این آمار فقط نوک کوه یخ است. نسل جدید AI for Software Engineering فراتر از تکمیل خودکار یک خط کد رفته است و از عامل‌های هوشمندی و مدل‌های بزرگ زبانی استفاده می‌کند که می‌توانند یک وظیفه end-to-end را انجام دهند.به طور مثال یک عامل هوشمند می‌تواند درخواست توسعه‌دهنده را بفهمد، کد را بنویسد، آن را کامپایل کند، تست‌های مرتبط را اجرا کند و در نهایت commit را بزند.نکته قابل توجه اینجاست که این ابزارها با استفاده از حافظه سازمانی و قوانین خاص هر کسب و کار، دانش و استانداردهای داخلی را جذب می‌کنند و خروجی‌هایشان را با آنها هماهنگ می‌سازند. و نقطه تمایز AI for Software Engineering  در درک هدف است و فقط الگوی بعدی نمی‌پردازد. هشدار:آیا هوش مصنوعی جایگاه انسان را تصاحب می‌کند؟نکته کلیدی این است که این ابزارها قرار نیست جای توسعه‌دهنده را بگیرند. بلکه مانند یک دستیار هوشمند عمل می‌کنند که کارهای تکراری و زمان‌بر را حذف می‌کند. تصمیم‌گیری معماری، درک محدودیت‌های کسب‌وکار، و مسئولیت اخلاقی محصول همچنان بر عهده انسان است.عوارض استفاده از این روش چیست؟اول از همه این روش وابستگی به مدل زبانی خاص خود را دارد یعنی  اگر مدل تغییر کند یا هزینه دسترسی به آن افزایش یابد، کل فرآیند توسعه تحت تأثیر قرار می‌گیرد. دوم، خطر تولید کدهای دارای خطاهای امنیتی یا نقض حق نشر است. مدل‌های زبانی از داده‌های عمومی آموزش دیده‌اند و ممکن است کدی تولید کنند که کپی غیرمجاز باشد. و سوم، هزینه محاسباتی بالا برای اجرای مدل‌های بزرگ در داخل سازمان است و همچنین، تیم‌ها باید زمان بگذارند تا خروجی هوش مصنوعی را بازبینی و تأیید کنند که خود نوعی هزینه پنهان است. منابعAwesome-AI4SE. (2021). GitHub repository. Retrieved from https://github.com/holunda-io/awesome-ai4seAI-SE Research Group. (n.d.). Leipzig University. Retrieved from https://ai-se.github.ioSeerene. (n.d.). AI-powered software engineering analytics. Retrieved from https://www.seerene.com ایستگاه چهارم : Software Engineering for AIانسان در خدمت هوش مصنوعیمفهوم Software Engineering for AIحتماً این جمله را شنیده‌اید که: داده، نفت جدید است. اما استخراج این نفت بدون مهندسی نرم‌افزار مناسب، غیرممکن است. سیستم‌های مبتنی بر هوش مصنوعی با نرم‌افزارهای سنتی تفاوت بنیادی دارند. در نرم‌افزار معمولی، رفتار توسط کد تعیین می‌شود. اما در سیستم‌های یادگیری ماشین، رفتار هم توسط کد و هم توسط داده شکل می‌گیرد. داده می‌تواند در طول زمان تغییر کند و باعث پیری مدل (Model Degradation) یا تغییر مفهوم (Concept Drift) شود. یعنی مدلی که امروز با دقت ۹۵ درصد پاسخ می‌دهد، سه ماه بعد ممکن است دقتش به ۶۰ درصد برسد، بدون اینکه یک خط از کد آن تغییر کرده باشد.در اینجا مفهوم Software Engineering for AI متولد شد. به زبان ساده،  SE4AI یعنی استفاده از اصول مهندسی نرم‌افزار برای بهتر کردن سیستم‌های مبتنی بر هوش مصنوعی است. هدف آن پل زدن بین دانشمندان داده و مهندسان نرم‌افزار است تا مدل‌های یادگیری ماشین بتوانند در محیط تولید به صورت مقیاس‌پذیر و پایدار اجرا شوند.  نمونه عملی این اصول شامل «تست واحد برای داده» (مثلاً بررسی ورودی‌ها با معیارهای مشخص)، «مدیریت نسخه داده و مدل» با ابزارهایی مانند DVC، و «پایش مداوم عملکرد» (نظارت بر دقت و تأخیر) است. دوره معروف دانشگاه کارنگی ملون با عنوان «Software Engineering for AI-Enabled Systems» یکی از منابع اصلی یادگیری در این حوزه است.باید توجه داشت که SE4AI با MLOps مرز مشترک دارد. اگر MLOps بگوید: چطور مدل را عملیاتی کنیم، SE4AI می‌گوید: چطور مدلی بسازیم که اصولاً قابلیت عملیاتی شدن داشته باشد. این دو مکمل یکدیگرند و گاهی با هم به کار می‌روند.آیا بدون مهندسی نرم‌افزار می‌توان یک سیستم AI ساخت؟خیلی از پروژه‌های هوش مصنوعی در مرحله نمونه اولیه موفق هستند، اما وقتی نوبت به یکپارچه‌سازی با سیستم‌هایlegacy، تأمین امنیت، مدیریت نسخه‌های مختلف مدل، و پایش در تولید می‌رسد، شکست می‌خورند. دلیلش این است که دانشمندان داده معمولاً با اصول مهندسی نرم‌افزار مانند تست‌پذیری، قابلیت نگهداری، و مقیاس‌پذیری آشنا نیستند.  مقاله کلاسیک گوگل با عنوان بدهی فنی پنهان در سیستم‌های یادگیری ماشین (۲۰۱۵) نشان می‌دهد که کد مدل تنها بخش کوچکی از یک سیستم واقعی است و بیشتر پیچیدگی در زیرساخت داده، پایش، و وابستگی‌ها پنهان است – دقیقاً جایی که SE4AI وارد می‌شود.عوارض نادیده گرفتن SE4AI چیست؟مدل‌ها در محیط production به مرور زمان از کار می‌افتند بدون اینکه کسی متوجه شود. هزینه بالای بازآموزی و استقرار دستی مدل‌ها به جای یک خط لوله خودکار است. و در آخر، افزایش بدهی فنی و دشواری نگهداری در بلندمدت می‌باشد.  منابعCarnegie Mellon University. (n.d.). Software Engineering for AI-Enabled Systems. Retrieved from https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=671076Jönköping University. (n.d.). SE4AI Programme. Retrieved from https://ju.se/en/study-at-ju/our-programmes/masterprogramme/software-engineering-for-ai.htmlAwesome-AI4SE. (2021). GitHub repository - SE4AI section. Retrieved from https://github.com/holunda-io/awesome-ai4se ایستگاه پنجم : Machine Learning Operationsمفهوم Machine Learning Operationsمفهوم Machine Learning Operationsحتماً برایتان پیش آمده که یک مدل یادگیری ماشین را در Jupyter Notebook ساخته‌اید، همه چیز عالی کار می‌کند، اما وقتی می‌خواهید آن را در برنامه واقعی و برای کاربران حقیقی اجرا کنید، سروکله صدها مشکل پیدا می‌شود. مدل کند است، حجمش بالاست، ورودی‌های دنیای واقعی با داده‌های آموزشی فرق دارد، و هیچ کس نمی‌داند چطور باید نسخه بعدی مدل را جایگزین نسخه قبلی کند بدون اینکه سرویس از کار بیفتد. Machine Learning Operations مجموعه شیوه‌هایی است که این چرخه حیات را مدیریت می‌کند. اگر DevOps را برای نرم‌افزار سنتی در نظر بگیریم، Machine Learning Operations معادل آن برای دنیای ML است. اما یک تفاوت کلیدی وجود دارد: در MLOps، علاوه بر کد، داده و مدل هم باید نسخه‌گذاری شوند.یک مقاله علمی در IEEE Xplore به چالش جالبی اشاره می‌کند. مدل‌های ML اغلب توسط افراد مختلف با زبان‌ها و فریم ورک‌های مختلف ساخته می‌شوند. عملیاتی‌کردن این مدل‌های ناهمگن کنار هم کار ساده‌ای نیست. راهکار معرفی‌شده در آن مقاله، پلتفرم Acumos است که می‌تواند مدل‌های سازگار را کشف کند، یک خط لوله از آنها بسازد، و کل را در یک کلیک روی AWS، GCP، Azure یا Kubernetes مستقر کند. خط لوله MLOps کامل شامل مراحلی مثل اسکن امنیتی image، تست دقت مدل، و پایش مدل در production است. Open Policy Agency (OPA) می‌تواند تصمیم بگیرد که مدل بر اساس امتیازات دقت، تأیید یا رد شود.عوارض نداشتن MLOps چیست؟اول، استقرار دستی و پرخطای مدل‌ها هر بار که دانشمند داده یک مدل جدید می‌سازد. دوم، عدم امکان بازگشت به نسخه قبلی مدل وقتی مدل جدید مشکل دارد. سوم، دیر متوجه شدن از کار افتادن مدل در تولید چون هیچ پایش خودکاری وجود ندارد. همچنین، تیم عملیات (Ops) و تیم داده مدام به خاطر مشکلات استقرار و اجرا با هم درگیر می‌شوند و بهره‌وری کلی پایین می‌آید. چه زمانی نه؟ اگر مدل‌ها را یک بار در سال آموزش می‌دهید و تا یک سال بعد تغییری در داده یا برچسب‌ها ایجاد نمی‌شود، تنظیم یک خط لوله MLOps کامل شبیه خریدن یک تراکتور برای باغچه حیات خلوت است. همان یک اسکریپت پایتونی که هر شش ماه یک بار دستی اجرایش می‌کنی، کافی است. منابعBhattacharjee, A., et al. (2021). MLOps: Creating powerful AI pipelines by stitching together heterogeneous Machine Learning models. IEEE Xplore. https://ieeexplore.ieee.org/document/9669143Harness Developer Hub. (n.d.). MLOps documentation. Retrieved from https://developer.harness.io/docs/continuous-delivery/machine-learning/Acumos Project. (n.d.). Acumos AI platform documentation. Retrieved from https://www.acumos.org/ایستگاه ششم : Infrastructure as Code نگاه اجمالی به Infrastructure as Codeمفهوم Infrastructure as Codeحتماً برایتان پیش آمده که برای راه‌اندازی یک سرور جدید، باید یک نفر ساعت‌ها پای ترمینال بنشیند و دستورات را یکی‌یکی تایپ کند. اگر آن شخص مرخصی برود یا مستنداتش را خوب ننوشته باشد، راه‌اندازی دوباره همان زیرساخت ممکن است روزها طول بکشد. این دقیقاً همان مشکلی است که Infrastructure as Code حل می‌کند.طبق یک مقاله علمی در نشریه KHPI، فریم‌ورک‌های IaC به چهار دسته اصلی تقسیم می‌شوند: ابزارهای استقرار و مدیریت پیکربندی، ابزارهای تهیه زیرساخت، ابزارهای مجازی‌سازی و کانتینر، و چهارمی ابزارهای زمان اجرا است. اما مشکل اینجاست که در عمل، یک برنامه پیچیده اغلب نیاز به استفاده همزمان از چندین فریم‌ورک دارد و دانش عمیق از همه آنها برای یک تیم سخت است.باید توجه داشت که IaC به معنای نوشتن اسکریپت‌های خطی نیست. بلکه توصیف اعلانی (declarative) از زیرساخت مورد نظر است. مثلاً در Terraform شما می‌گویید «من یک ماشین مجازی با ۴ گیگ رم و ۲ پردازنده می‌خواهم»، نه اینکه «اول این دستور را بزن، بعد آن دستور را بزن». ابزار خودش می‌فهمد چه چیزی کم و چه چیزی اضافه است.هشدار: آیا می‌توان زیرساخت را با اسکریپت‌های bash مدیریت کرد؟ برای یک سرور، بله اما برای ده سرور با محیط‌های متفاوت (توسعه، تست، تولید)، جواب خیر است. اسکریپت‌های bash خطی هستند و وضعیت فعلی زیرساخت را ردیابی نمی‌کنند. اگر یک دستور سه بار اجرا شود، ممکن است خراب شود. اما ابزارهای IaC مثل Terraform وضعیت زیرساخت را در یک فایل state ذخیره می‌کنند و فقط تغییرات لازم را اعمال می‌کنند.عوارض نادیده گرفتن IaC چیست؟اول، محیط‌های توسعه، تست و تولید با هم فرق می‌کنند و باگ‌ها فقط در تولید ظاهر می‌شوند. دوم، راه‌اندازی مجدد زیرساخت پس از یک فاجعه (مثل آتش‌سوزی در دیتاسنتر) روزها یا هفته‌ها طول می‌کشد. سوم، هیچ مستند زنده‌ای از زیرساخت وجود ندارد و دانش فقط در ذهن چند نفر خاص محبوس می‌شود. همچنین، هر تغییر زیرساخت نیاز به حضور آن افراد خاص دارد و تیم نمی‌تواند به صورت خودگردان عمل کند. منابعWurster, M., Breitenbücher, U., Falkenthal, M., & Leymann, F. (2021). DOML: A new modeling approach for Infrastructure as Code. ScienceDirect. https://www.sciencedirect.com/science/article/pii/S016412122100143XHashiCorp. (n.d.). Terraform documentation. Retrieved from https://www.terraform.io/docsRed Hat. (n.d.). Ansible documentation. Retrieved from https://docs.ansible.com  ایستگاه هفتم : API Gateway & Service Meshمفهوم API Gateway & Service Meshمفهوم API Gateway & Service Meshحتماً شنیده‌اید که در معماری میکروسرویس، سرویس‌ها باید با هم حرف بزنند. اما این «حرف زدن» دو نوع کاملاً متفاوت دارد. یکی ترافیک ورودی از بیرون به داخل مثل وقتی یک اپلیکیشن موبایل سرور را صدا می‌زند و دیگری ترافیک بین خود سرویس‌ها در داخل دیتاسنتر مثل وقتی سرویس پرداخت با سرویس انبار حرف می‌زند. دو ابزار متفاوت برای این دو نوع ترافیک طراحی شده‌اند: API Gateway برای ترافیک شمال-جنوب (ورودی)Service Mesh برای ترافیک شرق-غرب (داخلی)API Gateway دروازه ورودی سیستم است. وقتی درخواستی از بیرون می‌آید، اول به آن می‌رسد. کارهایش شامل مسیریابی به سرویس مناسب، احراز هویت کاربر، محدود کردن نرخ درخواست‌ها و جمع کردن پاسخ چند سرویس در یک پاسخ است. اما Service Mesh در لایه پایین‌تری کار می‌کند.ایدیت لوین، بنیانگذار Solo.io، در مصاحبه با InfoQ گفت برخلاف Kubernetes که برنده قطعی orchestration شد، در حوزه service mesh احتمالاً هیچ برنده مشخصی وجود نخواهد داشت. پیاده‌سازی‌هایی مثل Istio، LinkerD، Consul Connect و AppMesh آمازون هرکدام نقاط قوت و ضعف خود را دارند. برای یکسان کردن زبان پیکربندی همه آنها، مشخصاتی به نام Service Mesh Interface  تعریف شده است.باید توجه داشت که API Gateway و Service Mesh رقیب هم نیستند. یک معماری بالغ می‌تواند هر دو را داشته باشد Gateway پشت لودبالانسر اصلی می‌نشیند و ترافیک ورودی را مدیریت می‌کند و  Mesh در لایه پایین‌تر، بین سرویس‌ها، امنیت و مشاهده‌پذیری را تأمین می‌کند.آیا می‌توان از API Gateway به جای Service Mesh استفاده کرد؟برای سیستم‌های بزرگ با صدها سرویس که نیاز به رمزگذاری داخلی، قطع‌کننده مدار، و انتشار قناری دارند خیر، زیرا API Gatewayبرای ترافیک ورودی بهینه شده و قرار دادن تمام منطق ارتباط بین سرویس‌ها در آن، آن را به یک گلوگاه و نقطه شکست تبدیل می‌کند.عوارض استفاده نکردن از Service Mesh چیست؟اول، امنیت ارتباط بین سرویس‌ها به جای mTLS خودکار، به تنظیم دستی گواهی‌ها وابسته است که به شدت خطاپذیر است. دوم، مشاهده‌پذیری ترافیک داخلی محدود است و اشکال‌زدایی مشکلات بین سرویس‌ها سخت می‌شود. سوم، پیاده‌سازی الگوهایی مانند قطع‌کننده مدار و انتشار قناری به صورت دستی در هر سرویس، کد تکراری و مستعد باگ ایجاد می‌کند. همچنین، تغییر در زیرساخت شبکه (مثل اضافه کردن رمزگذاری) نیاز به تغییر در تک تک سرویس‌ها دارد.منابعLevine, I. (2020). Idit Levine on Gloo, Service Mesh Interface, and WebAssembly Hub. InfoQ Podcast. Retrieved from https://www.infoq.com/podcasts/gloo-service-mesh-interface-webassembly/Solo.io. (n.d.). Gloo Edge documentation. Retrieved from https://docs.solo.io/gloo-edge/latest/Service Mesh Interface (SMI). (n.d.). SMI specification. Retrieved from https://smi-spec.io/ایستگاه هشتم : Command Query Responsibility Segregation نگاهی به عملکرد Command Query Responsibility Segregationمفهوم Command Query Responsibility Segregationحتماً برایتان پیش آمده که در یک سیستم، تعداد درخواست‌های خواندن چندین برابر درخواست‌های نوشتن است. مثلاً در یک فروشگاه آنلاین، هزاران کاربر محصولات را می‌بینند، اما تعداد سفارش‌های جدید شاید در همان لحظه فقط ده تا باشد. اگر از یک مدل داده واحد برای هر دو استفاده کنید، درخواست‌های سنگین خواندن، سرعت نوشتن را پایین می‌آورند و برعکس این موضوع هم صادق است.CQRS  جدا کردن مدل نوشتن از مدل خواندن است. مدل Command مسئول تغییر وضعیت است مانند ایجاد سفارش جدید و از اصول Domain Driven Design پیروی می‌کند. مدل Query فقط برای نمایش داده بهینه شده و می‌تواند از یک دیتابیس کاملاً متفاوت مثل Elasticsearch  استفاده کند.پروژه Mixter که به چندین زبان پیاده شده، یک نمونه عملی از CQRS در کنار Event Sourcing است.باید توجه داشت که این جداسازی هزینه دارد: همگام‌سازی بین دو مدل نیاز به رویدادها یا پیام‌های غیرهمگام دارد.عوارض استفاده از CQRS چیست؟اول، افزایش پیچیدگی کد و معماری. دوم، تأخیر در همگام‌سازی بین مدل خواندن و نوشتن سوم، نیاز به زیرساخت پیام‌رسان برای انتقال رویدادها بین دو مدل. همچنین، تیم باید با دو مدل داده جداگانه کار کند که درک و دیباگ کردن سیستم را سخت‌تر می‌کند.اگر شما یک سیستم ساده‌ای می‌نویسید که نرخ خواندن و نوشتن به هم نزدیک است، و منطق دامین پیچیدگی خاصی ندارد، CQRS را فراموش کنید. هزینه جداسازی مدل‌ها، همگام‌سازی بین آنها، و پیچیدگی ذهنی که به تیم تحمیل می‌کند، از هر سودی بیشتر است.منابعMixter Project. (n.d.). CQRS and Event Sourcing in multiple languages. GitCode. Retrieved from https://gitcode.com/gh_mirrors/mi/mixterFowler, M. (2011). CQRS. MartinFowler.com. Retrieved from https://martinfowler.com/bliki/CQRS.htmlMicrosoft Learn. (n.d.). CQRS pattern. Retrieved from https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrsایستگاه نهم : Event-Driven Architectureنگاهی اجمالی به معماری Event-Drivenمفهوم Event-Driven Architectureحتماً برایتان پیش آمده که در یک سیستم، سرویس A باید با سرویس B حرف بزند. در معماری سنتی، A مستقیم B را صدا می‌زند و منتظر می‌ماند. اگر B پایین باشد، A هم مختل می‌شود. اگر B کند باشد، A هم کند می‌شود. این همان معماری درخواست-پاسخ همگام است.معماری رویدادمحور این گره را باز می‌کند. درEDA، سرویس A به جای صدا زدن مستقیمB، یک رویداد منتشر می‌کند (مثلاً «سفارش جدید ثبت شد») و کارش تمام است. هر سرویسی که به این رویداد علاقه داشته باشد (پرداخت، انبار، ایمیل) آن را دریافت و پردازش می‌کند. تولیدکننده از مصرف‌کنندگان خبر ندارد و مصرف‌کننده‌ها هم از یکدیگر بی‌خبرند.سه فناوری رایج در این حوزه نقش‌های متفاوتی دارند. Kafka  برای رویدادهای بلندمدت مناسب است (مثل تاریخچه ثبت‌نام کاربران) و پیام را برای همیشه نگه می‌دارد. RabbitMQ  برای فرمان‌ها و تسک‌ها بهینه است (مثل ارسال ایمیل) و پیام را پس از تحویل حذف می‌کند. gRPC برای تماس‌های همگام با تأخیر پایین (مثل اعتبارسنجی سریع) استفاده می‌شود. در یک سیستم واقعی، هر سه می‌توانند کنار هم کار کنند.باید توجه داشت که EDA شل‌شدگی و مقیاس‌پذیری می‌آورد، اما هزینه‌اش پیچیدگی دیباگ کردن است. وقتی یک رویداد چندین سرویس را زنجیره‌وار تحریک می‌کند، فهمیدن اینکه «چرا این اتفاق نیفتاد» ساعتها وقت می‌برد. منابعJava Code Geeks. (2021). Polyglot Event-Driven Systems with Kafka, RabbitMQ and gRPC. Retrieved from https://www.javacodegeeks.com/2021/03/polyglot-event-driven-systems-with-kafka-rabbitmq-and-grpc.htmlMotia Framework. (n.d.). Event-driven step-based architecture. Retrieved from https://motia.devTNGlobal. (2024). Why Event-Driven Architecture is crucial for Agentic AI. Retrieved from https://tnGlobal.com ایستگاه دهم : Serverless Architectureنگاه اجمالی به معماری Serverlessمفهوم Serverless Architectureحتماً برایتان پیش آمده که برای اجرای یک تابع ساده، مجبورید یک سرور کامل راه‌اندازی کنید، سیستم عامل نصب کنید، و نگران مقیاس‌پذیری و در دسترس بودن آن باشید. Serverless فراموش کردن همه این دغدغه‌ها است. شما فقط کدتان را می‌دهید، بقیه با ارائه‌دهنده ابراست.Serverless بر دو پایه اصلی استوار است :Function as a Service مثل AWS Lambda که واحد اجرا یک تابع است.Backend as a Service مثل دیتابیس‌های مدیریت‌شده است.باید توجه داشت که Serverless به معنای نبودن سرور نیست. سرور همیشه هست، اما مدیریت آن به طور کامل بر عهده ارائه‌دهنده ابر است. همچنین هر تابع به طور مستقل مقیاس می‌شود. اگر تابع پردازش تصویر صد برابر شود، تابع احراز هویت تحت تأثیر قرار نمی‌گیرد.یک راهنمای عملی از Pulumi نشان می‌دهد که یکی از جذابیت‌های سرورلس، توانایی ترکیب زبان‌های مختلف در یک پروژه است. مثلاً می‌توانی یک تابع به زبان پایتون برای پردازش داده سنگین بنویسی، یک تابع به زبان Go برای API با کارایی بالا، و یک تابع TypeScript برای هندل کردن webhookها اما هر تابع به طور مستقل scale می‌شود. اگر ترافیک تابع پایتون صد برابر شود، روی تابع Go هیچ تأثیری نمی‌گذارد. هزینه هم فقط به ازای زمان اجرا و تعداد فراخوانی محاسبه می‌شود. برای توابعی که گاهی هفته‌ها فراخوانی نمی‌شوند، این مدل قیمت‌گذاری فوق‌العاده به صرفه است. نکته دیگر اینکه آدرس HTTPS هر تابع در طول به‌روزرسانی‌ها ثابت می‌ماند و نیازی به تغییر در سمت کلاینت نیست.هشدار: آیا سرورلس برای همه workloadها مناسب است؟اگر برنامه شما همیشه روشن است و ترافیک ثابتی دارد، هزینه Serverless ممکن است از یک سرور سنتی بیشتر شود. همچنین cold start (تأخیر راه‌اندازی تابع پس از چند دقیقه بیکاری) می‌تواند برای برنامه‌های حساس به تأخیر کشنده باشد.عوارض استفاده از سرورلس چیست؟cold start تأخیر قابل توجهی به پاسخ اضافه می‌کند. وابستگی شدید به ارائه‌دهنده ابر و قفل شدن در آن.  رخ می‌دهد. دیباگ کردن توابع توزیع‌شده سخت‌تر از یک برنامه monolithic است. همچنین، محدودیت‌هایی در زمان اجرا (معمولاً ۱۵ دقیقه) و حافظه وجود دارد که همه workloadها را پشتیبانی نمی‌کند.منابعPulumi. (n.d.). Deploy multi-language serverless functions on Google Cloud. Retrieved from https://www.pulumi.com/docs/guides/crosswalk/gcp/serverless/Amazon Web Services. (n.d.). AWS Lambda documentation. Retrieved from https://docs.aws.amazon.com/lambda/ Serverless Architecture. Retrieved from https://developer.baidu.comایستگاه یازدهم : API-first Approachمفهوم API-first Approachمفهوم API-first Approachحتماً برایتان پیش آمده که تیم فرانت‌اند و بک‌اند همزمان کار می‌کنند، اما وقتی زمان یکپارچه‌سازی می‌رسد، می‌بینند APIهایی که هرکدام ساخته‌اند با هم جور درنمی‌آید. API-first یعنی قبل از نوشتن هر کدی، اول مشخصات API را با استانداردی مثل OpenAPI (Swagger) طراحی و مستند کنید. همه تیم‌ها روی آن توافق می‌کنند و بعد کدشان را می‌نویسند.تیم Algolia که خدمات جستجو ارائه می‌دهد، با این روش توانسته، ده API و یازده زبان برنامه‌نویسی را با سه مهندس نگهداری کند. به این صورت: از روی مشخصات OpenAPI، هشتاد درصد کد SDKها به صورت خودکار تولید می‌شود. خط لوله تولید تا انتشار در npm، PyPI و Maven حدود ۲۰ دقیقه طول می‌کشد.از نظر منAPI-first بیش از یک رویکرد فنی، یک قرارداد اجتماعی بین تیم‌هاست. می‌گوید: ما اول توافق می‌کنیم چطور حرف بزنیم، بعد هر کد می‌رویم کدمان را می‌نویسیم. بدون این توافق، دو تیم موازی ممکن است هفته‌ها کار کنند و آخر سر ببینند APIهایشان با هم جور درنمی‌آید.آیا می‌توان بدون API-first کار کرد؟ برای یک تیم کوچک و یک پروژه ساده، بله اما برای چندین تیم که روی سرویس‌های مختلف کار می‌کنند، دیر یا زود به تضاد و دوباره‌کاری می‌رسید.عوارض استفاده نکردن از API-first چیست؟اول، دوباره‌کاری و اتلاف وقت در یکپارچه‌سازی. دوم، مستندات قدیمی و بی‌اعتبار که با کد همخوانی ندارد. سوم، وابستگی تیم‌ها به هم که پیشرفت را کند می‌کند. همچنین، تولید SDK برای زبان‌های مختلف به صورت دستی غیرممکن می‌شود.منابعAlgolia Engineering. (2021). How we generate 100+ SDKs. Retrieved from https://engineering.algolia.com/blog/how-we-generate-100-plus-sdksOpenAPI Initiative. (n.d.). OpenAPI Specification (Swagger). Retrieved from https://www.openapis.org/Anthropic. (2024). Model Context Protocol (MCP). Retrieved from https://www.anthropic.com/mcp ایستگاه دوازدهم :  Domain Driven Designکتاب Domain Driven Designمفهوم Domain Driven Designحتماً برایتان پیش آمده که یک تیم توسعه و متخصصان کسب‌وکار از یک واژه معنای متفاوتی می‌فهمند. مثلاً «مشتری» برای تیم فنی یک رکورد در دیتابیس است، اما برای تیم فروش معنای پیچیده‌تری دارد. این اختلاف زبان، ریشه بسیاری از پروژه‌های شکست‌خورده است.اریک ایوانز در کتاب معروفش (Blue Book) راه‌حلی به نام Domain Driven Design ارائه کرد. ایده مرکزی به این صورت است که: تیم توسعه باید با متخصصان دامین بنشیند و یک مدل مشترک از کسب‌وکار بسازد. این مدل به یک زبان یکپارچه تبدیل می‌شود که هم در جلسات و هم در کد استفاده می‌شود.باید توجه داشت که DDD برای سیستم‌هایی با منطق کسب‌وکار پیچیده مثل بیمه و مالی طراحی شده، نه برای فرم‌های ساده ثبت‌نام.هشدار: آیا هر پروژه‌ای به DDD نیاز دارد؟برای سیستم‌های ساده مثل یک وبلاگ یا فروشگاه کوچک، DDD وزن اضافه است. پیاده‌سازی Aggregate و Repository و Value Object بدون داشتن منطق پیچیده، فقط کدزنی بی‌نتیجه است و باعث پیچیدگی بیشتر کد و نیاز به حضور دائمی متخصص دامین در کنار تیم توسعه دارد. منابعEvans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.Vernon, V. (2013). Implementing Domain-Driven Design. Addison-Wesley.Fowler, M. (n.d.). Domain Driven Design. MartinFowler.com. Retrieved from https://martinfowler.com/tags/domain%20driven%20design.htmlایستگاه سیزدهم : Hexagonal Architectureمعماری Hexagonal مفهوم Hexagonal Architectureحتماً برایتان پیش آمده که یک تغییر ساده در پایگاه داده یا سرویس خارجی، کل برنامه را تحت تأثیر قرار می‌دهد. مثلاً وقتی می‌خواهید از MySQL به PostgreSQL مهاجرت کنید، باید لایه business را هم تغییر دهید. مشکل از جایی است که لایه‌ها به ترتیب به هم وابسته‌اند. این وابستگی باعث می‌شود تست کردن لایه business بدون پایگاه داده واقعی سخت شود و تغییر یک فناوری مثل عوض کردن دیتابیس از SQL به NoSQL کل برنامه را تحت تأثیر قرار دهد.معماری هگزاگونال که Ports & Adapters هم نامیده می‌شود این وابستگی را برعکس می‌کند. لایه دامین یا منطق کسب‌وکار در مرکز قرار می‌گیرد و هیچ دانشی از دنیای خارج ندارد. ارتباط با خارج، تنها از طریق پورت interface تعریف می‌شود. «اداپتورها» کار تبدیل را انجام می‌دهند. مثلاً اداپتور REST درخواست HTTP را به فراخوانی متد مناسب تبدیل می‌کند. اداپتور دیتابیس پیاده‌سازی خاص ذخیره‌سازی را فراهم می‌کند.نکته جالب این است که: برای تست کردن دامین، فقط کافی است یک اداپتور تست بنویسید که به جای دیتابیس واقعی، داده را در حافظه ذخیره کند. برای تغییر دیتابیس هم فقط یک اداپتور جدید می‌نویسید؛ لایه دامین اصلاً عوض نمی‌شود.باید توجه داشت که اسم «هگزاگونال» قراردادی است و ربطی به شش ضلع ندارد. می‌تواند سه پورت یا نه پورت داشته باشد. اصل این است که وابستگی‌ها به سمت داخل اشاره می‌کنند.هشدار: آیا معماری هگزاگونال برای همه پروژه‌ها مناسب است؟اگر پروژه‌تان ساده است و احتمال تغییر زیرساخت در آینده نزدیک وجود ندارد، لایه‌بندی اضافه فقط زمان توسعه را می‌برد. این معماری برای سیستم‌هایی با طول عمر بالا و نیاز به تست‌پذیری زیاد ارزش دارد. در غیر این صورت، تعداد کلاس‌ها و فایل‌ها افزایش می‌یابد،درک جریان داده برای تازه‌واردها سخت‌تر است و برای پروژه‌های خیلی کوچک، زمان توسعه را افزایش می‌دهد. همچنین، ممکن است تیم حس کند برای کاری ساده، پیچیدگی زیادی ساخته است.منابعCockburn, A. (2005). Hexagonal Architecture. AlistairCockburn.us. Retrieved from https://alistair.cockburn.us/hexagonal-architecture/Hombergs, T. (2018). Get Your Hands Dirty on Clean Architecture. Leanpub.Graca, H. (n.d.). Hexagonal Architecture. HerbertoGraca.com. Retrieved from https://herbertograca.com/tag/hexagonal-architecture/ ایستگاه چهاردهم : Event Sourcingنگاه اجمالی به پترن Event Sourcingمفهوم Event Sourcingبه جای ذخیره وضعیت فعلی یک شیء، تمام اتفاقاتی که برای آن شیء افتاده را ذخیره کن!فرض کنید بخواهید بدانید که یک سفارش در طول زمان چه تغییراتی کرده است. در دیتابیس معمولی، فقط وضعیت فعلی را دارید برای حل این مشکل چه راهکاری دارید؟Event Sourcing این مشکل را حل می‌کند. به جای ذخیره وضعیت فعلی، تمام اتفاقاتی که برای یک شیء افتاده را ذخیره می‌کند. به طور مثال برای یک حساب بانکی تمامی تغییرات و تاریخچه شی ذخیره میشود: «حساب با ۱۰۰۰ تومان افتتاح شد»، «۵۰۰ تومان برداشت شد»، «۲۰۰ تومان واریز شد».وضعیت فعلی شی از بازپخش این رویدادها به دست می‌آید.با این راهکار تاریخچه کامل و قابلیت ممیزی در دسترس شماست. می‌توانید سیستم را در هر لحظه از گذشته بازسازی کنید.برای جلوگیری از بازپخش طولانی، از «اسنپ‌شات» (ذخیره وضعیت هر چند وقت یکبار) استفاده می‌شود.باید توجه داشت که Event Sourcing اغلب با CQRS ترکیب می‌شود. رویدادها از Aggregate خارج و منتشر می‌شوند و مدل Query جداگانه از آنها Viewهای خود را می‌سازد.Event Sourcing  یک فناوری نیست، یک تعهد است. وقتی رویدادها را ذخیره کردید، دیگر نمی‌توانید به راحتی ساختارشان را عوض کنید. هر تغییر در schema رویدادها باید backward compatible باشد یا migration بنویسید. اگر نیازی به تاریخچه و ممیزی ندارید، Event Sourcing فقط پیچیدگی اضافه می‌کند. وقتی رویدادها را ذخیره کردید، تغییر ساختارشان بسیار سخت است و نیاز به migration دارد. منابعFowler, M. (2005). Event Sourcing. MartinFowler.com. Retrieved from https://martinfowler.com/eaaDev/EventSourcing.htmlYoung, G. (n.d.). Event Sourcing. CodeBetter. Retrieved from https://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/Mixter Project. (n.d.). CQRS and Event Sourcing implementation. GitCode. ایستگاه پانزدهم : Low-code/No-code platforms Low-code/No-code مفهوم Low-code/No-code platformsحتماً برایتان پیش آمده که یک ایده ساده برای یک ابزار داخلی شرکت داشته‌اید، اما پیاده‌سازی آن با کدنویسی سنتی چند هفته زمان می‌برد. سکوهای Low-code و No-code این مشکل را حل می‌کنند. با کشیدن و رها کردن کامپوننت‌ها و تعریف جریان کاری می‌توانید در عرض چند روز یک اپلیکیشن کاربردی بسازید.سکوی Low-code و No-code به کاربران اجازه می‌دهند برنامه بسازند بدون اینکه خطی کد بنویسند یا با کمترین کدنویسی ممکن برانامه خود را بسازند. برای روشن شدن موضوع، به مثال DOML نگاه کنیم. در مقاله علمیDOML، محققان یک زبان مدل‌سازی به نام DOML طراحی کرده‌اند که یک لایه Low-code روی Infrastructure as Code است. یعنی کاربر که ممکن است متخصص زیرساخت نباشد می‌تواند با یک زبان ساده توصیف کند که اپلیکیشنش چه زیرساختی نیاز دارد. این یعنی کاربر بدون دانستن جزئیات Terraform یا Ansible، می‌تواند زیرساختش را روی چندین پلتفرم مختلف Provision کند. تفاوت Low-code و No-code چیست؟تفاوت Low-code و No-code در مخاطب است. No-code برای "شهروندان توسعه‌دهنده" (افراد غیرفنی مثل تحلیلگران کسب‌وکار) طراحی شده و هیچ راهی برای خروج از جعبه ندارد. Low-code برای توسعه‌دهندگان حرفه‌ای طراحی شده و امکان نوشتن کد سفارشی برای سناریوهای پیچیده را می‌دهد. نقطه ضعف اصلی هر دوی این سکوها وابستگی به فروشنده (Vendor Lock-in) است. وقتی برنامه‌ات روی یک پلتفرم Low-code خاص ساخته شد، بیرون آوردن آن به سختی ممکن است. سرویس‌هایی مثل OutSystems، Mendix و Power Apps در این حوزه فعال هستند.این سکوها برای MVP و ابزارهای داخلی عالی هستند.برای محصول اصلی یک شرکت فناوری چطور؟تجربه نشان داده است که دیر یا زود به مرز سکو برخورد می‌کنید یعنی چیزی که سکو نمی‌تواند انجام دهد شما را گرفتار می‌کند. منابعWurster, M., et al. (2021). DOML: A new modeling approach for Infrastructure as Code. ScienceDirect.OutSystems. (n.d.). Low-code platform documentation. Retrieved from https://www.outsystems.comMendix. (n.d.). Low-code platform. Retrieved from https://www.mendix.com  ایستگاه شانزدهم : Business Process Management SystemsBusiness Process Management Systemsمفهوم Business Process Management Systemsحتماً برایتان پیش آمده که یک فرآیند کسب‌وکار مثل «ثبت سفارش تا تحویل» را بررسی کرده‌اید. این فرآیند ممکن است ده‌ها مرحله داشته باشد از تأیید اعتبار مشتری، چک کردن موجودی، تخصیص به انباردار، بسته‌بندی، ارسال تا پیامک به مشتری است. اگر بخواهید این را با کدنویسی سنتی پیاده کنید، خیلی زود درگیر پیچیدگی حالت‌های مختلف می‌شوید: اگر موجودی نبود چه؟ اگر مشتری پولش را پس گرفت چه؟BPMS با زبان استاندارد BPMN 2.0 این پیچیدگی را مدیریت می‌کند. فرآیند به صورت گرافیکی مدل می‌شود. تسک‌ها دو نوع هستند: تسک انسانی مثلاً «مدیر تأیید کند» و تسک خودکار مثلاً «وضعیت سفارش را به‌روز کن») موتور BPMS مثل Camunda، jBPM، مدل را اجرا و وضعیت هر نمونه را پیگیری می‌کند. وقتی یک تسک انسانی به پایان رسید، موتور به صورت خودکار مرحله بعد را شروع می‌کند. از دید معماری سازمانی، BPMS یک نقطه مرکزی برای دیده‌شدن و بهینه‌سازی فرآیندهای بین‌سیستمی است. داشبوردهای BPMS نشان می‌دهند کدام مرحله گلوگاه شده، کدام کارمند بیشترین تسک را انجام داده، و چقدر از SLAها عقب هستیم. BPMSهای مدرن با معماری رویدادمحور و سرورلس ترکیب می‌شوند تا فرآیندهای مقیاس‌پذیر بسازند.باید توجه داشت که BPMS زمانی می‌درخشد که فرآیندها مدام تغییر می‌کنند. اگر هر ماه یک مرحله جدید به گردش کار اضافه می‌شود، با BPMS فقط مدل را عوض می‌کنید، بدون اینکه نیاز به deploy دوباره کل نرم‌افزار باشد.عوارض استفاده از BPMS چیست؟اول، هزینه بالای پیاده‌سازی اولیه و خرید لایسنس (مخصوصاً نسخه‌های سازمانی). دوم، نیاز به تخصص در BPMN و موتورهای مربوطه. سوم، برای فرآیندهای بسیار ساده، BPMS وزن اضافه است. همچنین، ممکن است موتور BPMS برای سناریوهای با توان عملیاتی بسیار بالا (مثل میلیون‌ها درخواست در ثانیه) گلوگاه شود. منابعCamunda. (n.d.). BPMN 2.0 Engine documentation. Retrieved from https://camunda.comjBPM. (n.d.). jBPM documentation. Red Hat. Retrieved from https://www.jbpm.orgOMG. (2011). Business Process Model and Notation (BPMN) Version 2.0. Retrieved from https://www.omg.org/spec/BPMN/2.0   ایستگاه هفدهم : Message Queue (Kafka, RabbitMQ)Kafka vs RabbitMQمفهوم Message Queue (Kafka, RabbitMQ)Message Queue یک صف ارتباطی بین سرویس‌هاست. سرویس A پیام را در صف می‌گذارد و بدون اینکه منتظر بماند به کار خود ادامه می‌دهد. سرویس B یا چند سرویس وقتی وقت داشت می‌آید پیام را از صف برمی‌دارد و پردازش می‌کند. در معماری‌های مبتنی بر میکروسرویس، Message Queue یک مؤلفه کلیدی است. اما همه Message Queueها یکسان نیستند. دو نمونه بسیار محبوب، RabbitMQ و Apache Kafka، تفاوت‌های بنیادی دارند.یک مقاله عملی از Java Code Geeks این تفاوت را شفاف توضیح داده است RabbitMQ یک صف سنتی است. پیام را از صف حذف می‌کند بعد از اینکه مصرف‌کننده آن را دریافت کرد. برای سناریوهایی که "پیام دقیقاً یک بار پردازش شود" مهم است، مثل دستورات (commands) و تسک‌ها، مناسب است. در مقابل، Kafka یک commit log است. پیام‌ها را برای همیشه یا برای مدت مشخصی نگه می‌دارد و مصرف‌کننده تعیین می‌کند از کجا شروع به خواندن کند. یعنی می‌توانی یک پیام را چند بار بخوانی. برای رویدادهایی که "چه شد" مهم است و تاریخچه کامل آن ارزش دارد، مناسب است. در یک سیستم polyglot، اغلب هر دو را کنار هم می‌بینند: Kafka برای رویدادهایی مثل تاریخچه کاربران، چون می‌خواهی تاریخچه ثبت نام همه کاربران را داشته باشی وRabbitMQ برای فرمان‌هایی مثل ارسال ایمیل چون می‌خواهی ایمیل دقیقاً یک بار فرستاده شود.باید توجه داشت که انتخاب اشتباه بین این دو هزینه بالایی دارد. کافکا مثل کامیون است؛ اگر فقط می‌خواهید یک پاکت نامه بفرستید، راه‌اندازی کامیون بیهوده است RabbitMQ برای بسیاری از موارد نه فقط کافی، بلکه بهینه‌تر است. هشدار: آیا می‌توان بدون Message Queue کار کرد؟برای سیستم‌های خیلی ساده با تعداد سرویس کم، بله اما به محض اینکه بیش از ۳ سرویس داشته باشید که باید غیرهمگام با هم ارتباط برقرار کنند، Message Queue تبدیل به یک ضرورت می‌شود. منابعJava Code Geeks. (2021). Polyglot Event-Driven Systems with Kafka, RabbitMQ and gRPC. Retrieved from https://www.javacodegeeks.com/2021/03/polyglot-event-driven-systems-with-kafka-rabbitmq-and-grpc.htmlApache Kafka. (n.d.). Documentation. Retrieved from https://kafka.apache.org/documentation/RabbitMQ. (n.d.). Documentation. Retrieved from https://www.rabbitmq.com/documentation.html   ایستگاه هجدهم : Containers (Docker) , Container Orchestration (Kubernetes)Kubernetes vs dockerمفهوم Containers , Container Orchestrationحتماً برایتان پیش آمده که یک برنامه روی دستگاه شما کار می‌کند، اما روی دستگاه همکارتان از کار می‌افتد. مشکل وابستگی‌هاست. کتابخانه‌ای که شما دارید، او ندارد یا نسخه‌اش فرق می‌کند. کانتینرها این مشکل را حل می‌کنند. برنامه و همه وابستگی‌هایش در یک بسته قابل حمل به اسم Image جمع می‌شود. هر جا که Docker نصب باشد، Image دقیقاً یکسان اجرا می‌شود.تفاوت کانتینر با ماشین مجازی در این است که کانتینرها هسته سیستم‌عامل میزبان را به اشتراک می‌گذارند. نتیجه: کانتینرها در کسری از ثانیه بالا می‌آیند (در مقابل VM چند دقیقه  زمان می‌برد.حالا فرض کنید صدها کانتینر دارید. چه کسی تصمیم می‌گیرد هر کدام روی کدام سرور برود؟ اگر کانتینری خراب شد، چه کسی دوباره راه‌اندازی‌اش کند؟ اگر ترافیک بالا رفت، چه کسی تعداد کانتینرها را زیاد کند؟ اینجاست که Kubernetes وارد می‌شود Kubernetes یک ارکستراتور کانتینر است که تمام این کارها را خودکار می‌کند: زمان‌بندی، خودترمیمی، مقیاس خودکار، rolling update بدون قطعی، و سرویس‌دیسکاوری.باید توجه داشت که Kubernetes یک راه‌حل جادویی نیست. اگر فقط یک اپلیکیشن ساده روی یک سرور دارید، Kubernetes یعنی پیچیدگی بیش از حد و همین یک سرور با systemd و یک binary کافی است.هشدار: آیا هر برنامه‌ای به کانتینر و Kubernetes نیاز دارد؟برای تیم‌های کوچک با کمتر از ۵ سرویس، کانتینر ممکن است مفید باشد اما Kubernetes تقریباً همیشه زیاد است. Kubernetes زمانی معنا پیدا می‌کند که تیم شما بیش از ۵ نفر است، بیش از ۱۰ سرویس دارید، و نیاز به استقرار مکرر و مقیاس خودکار دارید. منابعDocker. (n.d.). Docker documentation. Retrieved from https://docs.docker.comKubernetes. (n.d.). Kubernetes documentation. Retrieved from https://kubernetes.io/docs/home/Wurster, M., et al. (2021). DOML: A new modeling approach for Infrastructure as Code. ScienceDirect. ایستگاه نوزدهم :  Multi-Tenancy Architectureمعماری Multi-Tenancyمفهوم Multi-Tenancy Architectureحتماً از جیمیل استفاده کرده‌اید. میلیاردها کاربر از یک برنامه واحد استفاده می‌کنند، اما هرکس فقط ایمیل‌های خودش را می‌بیند. این همان معماری (Multi-Tenancy) است: یک نمونه از نرم‌افزار به چندین مشتری سرویس می‌دهد و داده‌ها کاملاً از هم جدا می‌مانند.سه سطح اصلی برای پیاده‌سازی وجود دارد:دیتابیس جداگانه برای هر مشتری: بالاترین ایزوله‌سازی، اما تعداد دیتابیس‌ها زیاد می‌شودو هزینه بالا می‌رود.اسکیماهای جداگانه در یک دیتابیس مشترک:در این سرای ایزوله‌سازی خوب و هزینه متوسط است اما مدیریت backup پیچیده‌تر است.  یک اسکیما با فیلدtenant_id: بالاترین بهره‌وری از منابع اما سخت‌ترین پیاده‌سازی را دارد هر کوئری باید شامل tenant_id باشد تا کسی به داده دیگری دسترسی پیدا نکند.باید توجه داشت که انتخاب سطح multi-tenancy یکی از اولین و مهم‌ترین تصمیم‌ها در طراحی یک SaaS است. این تصمیم غیرقابل برگشت است؛ مهاجرت از دیتابیس جدا به اسکیماهای مشترک بسیار سخت و پرریسک است.آیا می‌توان از یک دیتابیس مشترک بدون فیلد tenant_id استفاده کرد؟فقط برای یک مستأجر، برای چند مستأجر،دیر یا زود داده‌ها قاطی می‌شوند و جداسازی آنها غیرممکن می‌گردد.عوارض انتخاب سطح نامناسب چیست؟اول، اگر ایزوله‌سازی را خیلی بالا بگیرید، هزینه زیرساخت و نگهداری افزایش می‌یابد. دوم، اگر خیلی پایین بگیرید خطر نشت داده بین مستأجرها به دلیل خطای برنامه‌نویسی وجود دارد. سوم، مهاجرت بین سطوح بسیار دشوار و زمان‌بر است. همچنین، پشتیبان‌گیری و بازیابی داده در سطوح مختلف پیچیدگی متفاوتی دارد. منابعMicrosoft Learn. (n.d.). Multi-tenant architecture patterns. Retrieved from https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overviewAWS SaaS Factory. (n.d.). Multi-tenant patterns. Retrieved from https://aws.amazon.com/saas/Fowler, M. (n.d.). Multi-Tenancy. MartinFowler.com. Retrieved from https://martinfowler.com/bliki/Multitenancy.htmlایستگاه بیستم : Data Migrationانتقال دادهمفهوم Data Migrationحتماً برایتان پیش آمده که بخواهید دیتابیس خود را از Oracle به PostgreSQL منتقل کنید، یا معماری برنامه را از monolithic به microservices تغییر دهید. در هر دو حالت، باید داده‌ها را از یک سیستم به سیستم دیگر منتقل کنید. این همان Data Migration است.فرآیند مهاجرت داده پنج مرحله اصلی دارد:کشف و پروفایل: ببینید چه داده‌ای دارید و کیفیت آن چطور است؟طراحی هدف: مدل داده جدید را مشخص کنید. توسعه: کدهای ETL بنویسید Extract, Transform, Loadتست: بررسی کنید همه داده درست منتقل شده باشد.اجرا: مرحله نهایی برش اجرا است.چالش‌های اصلی شامل داده‌های ناسازگار مثل فرمت‌های مختلف آدرس، زمان از کار افتادگی در حینcutover، و حفظ یکپارچگی ارجاعی بین جداول است.ابزارهایی مثل Liquibase و Flyway برای مهاجرت ساختار دیتابیس در طول زمان محبوب هستند همچنین AWS DMSو Azure Database Migration Service برای مهاجرت‌های ابری مناسب است. جالب اینجاست که Event Sourcing می‌تواند مهاجرت را ساده کند به صورتی که  اگر داده به صورت رویداد ذخیره شده باشد، کافی است رویدادها را در دیتابیس جدید بازپخش کنید تا وضعیت نهایی ساخته شود.باید توجه داشت که آزمایش در محیط production در مهاجرت داده، یک فاجعه است. تیم‌های حرفه‌ای معمولاً مهاجرت را سه بار تمرین می‌کنند (dry-run) قبل از اینکه بار چهارم اجرای واقعی را انجام دهند.هشدار!آیا می‌توان مهاجرت را بدون cutover انجام داد؟در الگوی dual-write، همزمان در دیتابیس قدیم و جدید نوشته می‌شود. ابتدا داده‌های تاریخی منتقل می‌شود، سپس برنامه به صورت همزمان در هر دو می‌نویسد، و بعد از اطمینان از هماهنگی، خواندن هم به دیتابیس جدید منتقل می‌شود. این روش downtime را به حداقل می‌رساند اما پیچیدگی بیشتری دارد.عوارض مهاجرت داده چیست؟اول، خطر از دست رفتن داده یا خراب شدن یکپارچگی ارجاعی دارد. دوما، زمان از کار افتادگی (downtime) در روش‌های ساده است. منابعMicrosoft Learn. (n.d.). Data migration overview. Retrieved from https://learn.microsoft.com/en-us/data-migration/AWS Database Migration Service. (n.d.). DMS documentation. Retrieved from https://aws.amazon.com/dms/Liquibase. (n.d.). Database migration tool. Retrieved from https://www.liquibase.orgFowler, M. (n.d.). Data Migration Patterns. MartinFowler.com. Retrieved from https://martinfowler.com/bliki/DataMigration.html مهسا دباغیانمهسا دباغیانSun, 31 May 2026 19:10:41 +0330https://virgool.ir/@m_17421119/بیست-مفهومی-که-هر-معمار-نرم-افزاری-باید-بداند-lh9rsg7kh6utورود از دریچه‌ای به دنیای بی‌کراندر سیاه‌چالهٔ نرم‌افزار و معماری نرم‌افزار، هر عبارت می‌تواند دری به سوی دنیایی بی‌کران باز کند.گاهی یک واژه آنقدر عمیق است که ماه‌ها طول می‌کشد تا مفهوم آن را به صورت کامل لمس کنید.در این پست، قصد دارم شما را به سفری دعوت کنم که در هر ایستگاه یکی از بیست مفهوم رایج، در معماری نرم‌افزار بیان می‌شود.تمام تلاش من این بوده است که توضیحات، ساده و روان باشند، بدون اینکه از دقت و جزئیات علمی کم شود.در نهایت اگر پس از خواندن این نوشته، بهره‌وری علمی و عملی‌تان بیشتر شود، به هدفم رسیده‌ام . این نوشته حاصل جستجو در منابع معتبر علمی (مقالات علمی، مستندات ابزارهای متن‌باز، و وبلاگ‌های مهندسی شرکت‌های بزرگ) است.ایستگاه اول : Chaos Engineeringآشوب کنترل شدهمفهوم Chaos Engineeringنوشته‌ها و تجربه‌های منتشرشده از تیم‌های بزرگی مثل نتفلیکس نشان می‌دهد که تاب‌آوری یک سیستم توزیع‌شده هیچ‌وقت قابل پیش‌بینی نیست. زیرا تعداد حالات خرابی آنقدر زیاد است که هیچ تست سنتی نمی‌تواند همه آن‌ها را پوشش دهد.Chaos Engineering دقیقاً برای همین مسئله طراحی شده است: این مفهوم برخلاف تصور عموم، به معنای خرابکاری تصادفی نیست، بلکه یک روش علمی و دقیق است. در این رویکرد، ابتدا حالت پایدار سیستم تعریف می‌شود، سپس فرضیه‌ای مطرح می‌شود و پس از آن، خطای موردنظر به صورت کنترل‌شده با یک شعاع انفجار محدود، مانند واکسن تزریق می‌شود. در این آزمایش هدف نهایی فرض کردن تاب آوری نخواهد بود بلکه اثبات تاب‌آوری است.تفاوت مهندسی آشوب با تست سنتی در این است که اولی در محیط واقعی  به صورت مداوم اجرا می‌شود، دومی در محیط تست، به صورت نقطه‌ای انجام می‌شود.یک مرور ادبیات گسترده که ۸۸ منبع را بین ژانویه ۲۰۱۹ تا آوریل ۲۰۲۴ بررسی کرده، نشان می‌دهد که سازمان‌های متوسط و بزرگ بیشترین استفاده را از این روش دارند. ابزارهایی متن‌باز مثل Kubernetes امکان تعریف سناریوهای خرابی را به صورت Chaos-as-Code فراهم می‌کنند. سناریوهای کلاسیک شامل قطع ارتباط بین سرویس‌ها مانند پارتیشن‌بندی شبکه، حذف تصادفی Podها، و تزریق تأخیر در پاسخ پایگاه داده است. کی این روش مناسب نخواهد بود؟ اگر سیستم‌ شما آنقدر ساده است که همه حالت‌های خرابی آن را از قبل می‌شناسی، یا اگر مشتری‌های حقیقی‌ کسب و کار شما تحمل قطعی حتی یک درصد را ندارند Chaos Engineering  گزینه مناسبی برای شما، نخواهد بود.منابعOwotogbe, J., Kumara, I., Van Den Heuvel, W., & Tamburri, D. A. (2024). Chaos Engineering: A Multi-Vocal Literature Review. arXiv preprint arXiv:2412.01416.Chaos Mesh. (n.d.). Chaos Mesh documentation: A Chaos Engineering platform for Kubernetes. CNCF Incubating Project. Retrieved from https://chaos-mesh.orgایستگاه دوم : Backend for Frontend Backend vs Frontendمفهوم Backend for Frontendفرض کنید، کسب و کار شما  یک اپلیکیشن موبایل و یک نسخه وب دارد که هر دو از یک سرور یکسان داده دریافت می‌کنند. صفحه اصلی در موبایل فقط به سه فیلد از پاسخ نیاز دارد، در حالی که وب به پانزده فیلد نیازمند است. اگر هر دو از یک API واحد استفاده کنند، یکی از این دو یا داده اضافه می‌گیرد یا مجبور است چندین درخواست جداگانه بفرستد.الگوی Backend for Frontend دقیقاً همین مشکل را حل می‌کند. به جای یک API Gateway عمومی، برای هر کلاینت یک backend اختصاصی ساخته می‌شود.این الگو را سام نیومن، معمار مشهور، در کتاب و مقالاتش به تفصیل توضیح داده است.باید توجه داشت که یک BFF فقط حاوی منطق ارائه است و نباید منطق دامین را در خود جای دهد. تیمی که مسئول frontend است، مالکیت BFF متناظر را نیز بر عهده دارد و هر دو با هم و همزمان deploy می‌شوند. در معماری‌های پلی‌گلات،چندزبانه اهمیت BFF این الگو بیشتر هم می‌شود، زیرا می‌تواند تفاوت‌های فنی بین پلتفرم‌ها را پنهان کند. مثلاً BFF می‌تواند داده مخصوص IOS را به فرمتی تبدیل کند که کتابخانه‌های خاص این پلتفرم بهتر متوجه شوند.یک اشتباه متداول BFF و API Gateway گاهی با هم اشتباه می‌شوند. یک راه متداول این است که API Gateway را به عنوان دروازه ورودی درنظرگرفته که درخواست را به BFF مناسب مثلاً BFF موبایل یا BFF وب هدایت کند. یعنی API Gateway مسیریابی می‌کند، BFF منطق ارائه را اجرا می‌کند. باید در نظر داشت که این دو رقیب هم نیستند بلکه به یکدیگر کمک می‌کنند. البته اگر فقط یک کلاینت وجود داشته باشد، BFF اضافه است و نیازی به استفاده از آن نیست.عوارض استفاده این الگو چیست؟با این الگو تعداد سرویس‌ها افزایش می‌یابد و هزینه نگهداری و پیچیدگی افزایش می‌یابد. همچنین افزودن لایه منجر به تاخیر میشود. عوارض احتمالی دیگر تکرار کد است .منابعMicrosoft Architecture Center. (n.d.). Backend for Frontend (BFF) pattern. Retrieved from https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontendsMotia Framework. (n.d.). Motia documentation: Step-based BFF implementation. Retrieved from https://motia.dev Newman, S. (2019). Building Microservices (2nd ed.). O'Reilly Media.ایستگاه سوم : AI for Software Engineeringهوش مصنوعی در خدمت انسانمفهوم AI for Software Engineeringاحتمالاً این روزها شنیده‌اید که توسعه‌دهندگان با کمک هوش مصنوعی کد می‌نویسند. اما نکته قابل توجه این است که برخی سازمان‌ها بیش از ۴۵ درصد کدهای جدید خود را با کمک هوش مصنوعی تولید می‌کنند. این آمار فقط نوک کوه یخ است. نسل جدید AI for Software Engineering فراتر از تکمیل خودکار یک خط کد رفته است و از عامل‌های هوشمندی و مدل‌های بزرگ زبانی استفاده می‌کند که می‌توانند یک وظیفه end-to-end را انجام دهند.به طور مثال یک عامل هوشمند می‌تواند درخواست توسعه‌دهنده را بفهمد، کد را بنویسد، آن را کامپایل کند، تست‌های مرتبط را اجرا کند و در نهایت commit را بزند.نکته قابل توجه اینجاست که این ابزارها با استفاده از حافظه سازمانی و قوانین خاص هر کسب و کار، دانش و استانداردهای داخلی را جذب می‌کنند و خروجی‌هایشان را با آنها هماهنگ می‌سازند. و نقطه تمایز AI for Software Engineering  در درک هدف است و فقط الگوی بعدی نمی‌پردازد. هشدار:آیا هوش مصنوعی جایگاه انسان را تصاحب می‌کند؟نکته کلیدی این است که این ابزارها قرار نیست جای توسعه‌دهنده را بگیرند. بلکه مانند یک دستیار هوشمند عمل می‌کنند که کارهای تکراری و زمان‌بر را حذف می‌کند. تصمیم‌گیری معماری، درک محدودیت‌های کسب‌وکار، و مسئولیت اخلاقی محصول همچنان بر عهده انسان است.عوارض استفاده از این روش چیست؟اول از همه این روش وابستگی به مدل زبانی خاص خود را دارد یعنی  اگر مدل تغییر کند یا هزینه دسترسی به آن افزایش یابد، کل فرآیند توسعه تحت تأثیر قرار می‌گیرد. دوم، خطر تولید کدهای دارای خطاهای امنیتی یا نقض حق نشر است. مدل‌های زبانی از داده‌های عمومی آموزش دیده‌اند و ممکن است کدی تولید کنند که کپی غیرمجاز باشد. و سوم، هزینه محاسباتی بالا برای اجرای مدل‌های بزرگ در داخل سازمان است و همچنین، تیم‌ها باید زمان بگذارند تا خروجی هوش مصنوعی را بازبینی و تأیید کنند که خود نوعی هزینه پنهان است. منابعAwesome-AI4SE. (2021). GitHub repository. Retrieved from https://github.com/holunda-io/awesome-ai4seAI-SE Research Group. (n.d.). Leipzig University. Retrieved from https://ai-se.github.ioSeerene. (n.d.). AI-powered software engineering analytics. Retrieved from  ایستگاه چهارم : Software Engineering for AIانسان در خدمت هوش مصنوعیمفهوم Software Engineering for AIحتماً این جمله را شنیده‌اید که: داده، نفت جدید است. اما استخراج این نفت بدون مهندسی نرم‌افزار مناسب، غیرممکن است. سیستم‌های مبتنی بر هوش مصنوعی با نرم‌افزارهای سنتی تفاوت بنیادی دارند. در نرم‌افزار معمولی، رفتار توسط کد تعیین می‌شود. اما در سیستم‌های یادگیری ماشین، رفتار هم توسط کد و هم توسط داده شکل می‌گیرد. داده می‌تواند در طول زمان تغییر کند و باعث پیری مدل (Model Degradation) یا تغییر مفهوم (Concept Drift) شود. یعنی مدلی که امروز با دقت ۹۵ درصد پاسخ می‌دهد، سه ماه بعد ممکن است دقتش به ۶۰ درصد برسد، بدون اینکه یک خط از کد آن تغییر کرده باشد.در اینجا مفهوم Software Engineering for AI متولد شد. به زبان ساده،  SE4AI یعنی استفاده از اصول مهندسی نرم‌افزار برای بهتر کردن سیستم‌های مبتنی بر هوش مصنوعی است. هدف آن پل زدن بین دانشمندان داده و مهندسان نرم‌افزار است تا مدل‌های یادگیری ماشین بتوانند در محیط تولید به صورت مقیاس‌پذیر و پایدار اجرا شوند.  نمونه عملی این اصول شامل «تست واحد برای داده» (مثلاً بررسی ورودی‌ها با معیارهای مشخص)، «مدیریت نسخه داده و مدل» با ابزارهایی مانند DVC، و «پایش مداوم عملکرد» (نظارت بر دقت و تأخیر) است. دوره معروف دانشگاه کارنگی ملون با عنوان «Software Engineering for AI-Enabled Systems» یکی از منابع اصلی یادگیری در این حوزه است.باید توجه داشت که SE4AI با MLOps مرز مشترک دارد. اگر MLOps بگوید: چطور مدل را عملیاتی کنیم، SE4AI می‌گوید: چطور مدلی بسازیم که اصولاً قابلیت عملیاتی شدن داشته باشد. این دو مکمل یکدیگرند و گاهی با هم به کار می‌روند.آیا بدون مهندسی نرم‌افزار می‌توان یک سیستم AI ساخت؟خیلی از پروژه‌های هوش مصنوعی در مرحله نمونه اولیه موفق هستند، اما وقتی نوبت به یکپارچه‌سازی با سیستم‌هایlegacy، تأمین امنیت، مدیریت نسخه‌های مختلف مدل، و پایش در تولید می‌رسد، شکست می‌خورند. دلیلش این است که دانشمندان داده معمولاً با اصول مهندسی نرم‌افزار مانند تست‌پذیری، قابلیت نگهداری، و مقیاس‌پذیری آشنا نیستند.  مقاله کلاسیک گوگل با عنوان بدهی فنی پنهان در سیستم‌های یادگیری ماشین (۲۰۱۵) نشان می‌دهد که کد مدل تنها بخش کوچکی از یک سیستم واقعی است و بیشتر پیچیدگی در زیرساخت داده، پایش، و وابستگی‌ها پنهان است – دقیقاً جایی که SE4AI وارد می‌شود.عوارض نادیده گرفتن SE4AI چیست؟مدل‌ها در محیط production به مرور زمان از کار می‌افتند بدون اینکه کسی متوجه شود. هزینه بالای بازآموزی و استقرار دستی مدل‌ها به جای یک خط لوله خودکار است. و در آخر، افزایش بدهی فنی و دشواری نگهداری در بلندمدت می‌باشد.  منابعCarnegie Mellon University. (n.d.). Software Engineering for AI-Enabled Systems. Retrieved from https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=671076Jönköping University. (n.d.). SE4AI Programme. Retrieved from https://ju.se/en/study-at-ju/our-programmes/masterprogramme/software-engineering-for-ai.htmlAwesome-AI4SE. (2021). GitHub repository - SE4AI section. Retrieved from https://github.com/holunda-io/awesome-ai4se ایستگاه پنجم : Machine Learning Operationsمفهوم Machine Learning Operationsمفهوم Machine Learning Operationsحتماً برایتان پیش آمده که یک مدل یادگیری ماشین را در Jupyter Notebook ساخته‌اید، همه چیز عالی کار می‌کند، اما وقتی می‌خواهید آن را در برنامه واقعی و برای کاربران حقیقی اجرا کنید، سروکله صدها مشکل پیدا می‌شود. مدل کند است، حجمش بالاست، ورودی‌های دنیای واقعی با داده‌های آموزشی فرق دارد، و هیچ کس نمی‌داند چطور باید نسخه بعدی مدل را جایگزین نسخه قبلی کند بدون اینکه سرویس از کار بیفتد. Machine Learning Operations مجموعه شیوه‌هایی است که این چرخه حیات را مدیریت می‌کند. اگر DevOps را برای نرم‌افزار سنتی در نظر بگیریم، Machine Learning Operations معادل آن برای دنیای ML است. اما یک تفاوت کلیدی وجود دارد: در MLOps، علاوه بر کد، داده و مدل هم باید نسخه‌گذاری شوند.یک مقاله علمی در IEEE Xplore به چالش جالبی اشاره می‌کند. مدل‌های ML اغلب توسط افراد مختلف با زبان‌ها و فریم ورک‌های مختلف ساخته می‌شوند. عملیاتی‌کردن این مدل‌های ناهمگن کنار هم کار ساده‌ای نیست. راهکار معرفی‌شده در آن مقاله، پلتفرم Acumos است که می‌تواند مدل‌های سازگار را کشف کند، یک خط لوله از آنها بسازد، و کل را در یک کلیک روی AWS، GCP، Azure یا Kubernetes مستقر کند. خط لوله MLOps کامل شامل مراحلی مثل اسکن امنیتی image، تست دقت مدل، و پایش مدل در production است. Open Policy Agency (OPA) می‌تواند تصمیم بگیرد که مدل بر اساس امتیازات دقت، تأیید یا رد شود.عوارض نداشتن MLOps چیست؟اول، استقرار دستی و پرخطای مدل‌ها هر بار که دانشمند داده یک مدل جدید می‌سازد. دوم، عدم امکان بازگشت به نسخه قبلی مدل وقتی مدل جدید مشکل دارد. سوم، دیر متوجه شدن از کار افتادن مدل در تولید چون هیچ پایش خودکاری وجود ندارد. همچنین، تیم عملیات (Ops) و تیم داده مدام به خاطر مشکلات استقرار و اجرا با هم درگیر می‌شوند و بهره‌وری کلی پایین می‌آید. چه زمانی نه؟ اگر مدل‌ها را یک بار در سال آموزش می‌دهید و تا یک سال بعد تغییری در داده یا برچسب‌ها ایجاد نمی‌شود، تنظیم یک خط لوله MLOps کامل شبیه خریدن یک تراکتور برای باغچه حیات خلوت است. همان یک اسکریپت پایتونی که هر شش ماه یک بار دستی اجرایش می‌کنی، کافی است. منابعBhattacharjee, A., et al. (2021). MLOps: Creating powerful AI pipelines by stitching together heterogeneous Machine Learning models. Harness Developer Hub. (n.d.). MLOps documentation. Retrieved Acumos Project. (n.d.). Acumos AI platform documentation. Retrieved ایستگاه ششم : Infrastructure as Codeنگاه اجمالی به Infrastructure as Code مفهوم Infrastructure as Codeحتماً برایتان پیش آمده که برای راه‌اندازی یک سرور جدید، باید یک نفر ساعت‌ها پای ترمینال بنشیند و دستورات را یکی‌یکی تایپ کند. اگر آن شخص مرخصی برود یا مستنداتش را خوب ننوشته باشد، راه‌اندازی دوباره همان زیرساخت ممکن است روزها طول بکشد. این دقیقاً همان مشکلی است که Infrastructure as Code حل می‌کند.طبق یک مقاله علمی در نشریه KHPI، فریم‌ورک‌های IaC به چهار دسته اصلی تقسیم می‌شوند: ابزارهای استقرار و مدیریت پیکربندی، ابزارهای تهیه زیرساخت، ابزارهای مجازی‌سازی و کانتینر، و چهارمی ابزارهای زمان اجرا است. اما مشکل اینجاست که در عمل، یک برنامه پیچیده اغلب نیاز به استفاده همزمان از چندین فریم‌ورک دارد و دانش عمیق از همه آنها برای یک تیم سخت است.باید توجه داشت که IaC به معنای نوشتن اسکریپت‌های خطی نیست. بلکه توصیف اعلانی (declarative) از زیرساخت مورد نظر است. مثلاً در Terraform شما می‌گویید «من یک ماشین مجازی با ۴ گیگ رم و ۲ پردازنده می‌خواهم»، نه اینکه «اول این دستور را بزن، بعد آن دستور را بزن». ابزار خودش می‌فهمد چه چیزی کم و چه چیزی اضافه است.هشدار: آیا می‌توان زیرساخت را با اسکریپت‌های bash مدیریت کرد؟ برای یک سرور، بله اما برای ده سرور با محیط‌های متفاوت (توسعه، تست، تولید)، جواب خیر است. اسکریپت‌های bash خطی هستند و وضعیت فعلی زیرساخت را ردیابی نمی‌کنند. اگر یک دستور سه بار اجرا شود، ممکن است خراب شود. اما ابزارهای IaC مثل Terraform وضعیت زیرساخت را در یک فایل state ذخیره می‌کنند و فقط تغییرات لازم را اعمال می‌کنند.عوارض نادیده گرفتن IaC چیست؟اول، محیط‌های توسعه، تست و تولید با هم فرق می‌کنند و باگ‌ها فقط در تولید ظاهر می‌شوند. دوم، راه‌اندازی مجدد زیرساخت پس از یک فاجعه (مثل آتش‌سوزی در دیتاسنتر) روزها یا هفته‌ها طول می‌کشد. سوم، هیچ مستند زنده‌ای از زیرساخت وجود ندارد و دانش فقط در ذهن چند نفر خاص محبوس می‌شود. همچنین، هر تغییر زیرساخت نیاز به حضور آن افراد خاص دارد و تیم نمی‌تواند به صورت خودگردان عمل کند. منابعWurster, M., Breitenbücher, U., Falkenthal, M., & Leymann, F. (2021). DOML: A new modeling approach for Infrastructure as Code. ScienceDirect.HashiCorp. (n.d.). Terraform documentation.Red Hat. (n.d.). Ansible documentation.  ایستگاه هفتم : API Gateway & Service MeshAPI Gateway & Service Meshمفهوم API Gateway & Service Meshحتماً شنیده‌اید که در معماری میکروسرویس، سرویس‌ها باید با هم حرف بزنند. اما این «حرف زدن» دو نوع کاملاً متفاوت دارد. یکی ترافیک ورودی از بیرون به داخل مثل وقتی یک اپلیکیشن موبایل سرور را صدا می‌زند و دیگری ترافیک بین خود سرویس‌ها در داخل دیتاسنتر مثل وقتی سرویس پرداخت با سرویس انبار حرف می‌زند. دو ابزار متفاوت برای این دو نوع ترافیک طراحی شده‌اند: API Gateway برای ترافیک شمال-جنوب (ورودی)Service Mesh برای ترافیک شرق-غرب (داخلی)API Gateway دروازه ورودی سیستم است. وقتی درخواستی از بیرون می‌آید، اول به آن می‌رسد. کارهایش شامل مسیریابی به سرویس مناسب، احراز هویت کاربر، محدود کردن نرخ درخواست‌ها و جمع کردن پاسخ چند سرویس در یک پاسخ است. اما Service Mesh در لایه پایین‌تری کار می‌کند.ایدیت لوین، بنیانگذار Solo.io، در مصاحبه با InfoQ گفت برخلاف Kubernetes که برنده قطعی orchestration شد، در حوزه service mesh احتمالاً هیچ برنده مشخصی وجود نخواهد داشت. پیاده‌سازی‌هایی مثل Istio، LinkerD، Consul Connect و AppMesh آمازون هرکدام نقاط قوت و ضعف خود را دارند. برای یکسان کردن زبان پیکربندی همه آنها، مشخصاتی به نام Service Mesh Interface  تعریف شده است.باید توجه داشت که API Gateway و Service Mesh رقیب هم نیستند. یک معماری بالغ می‌تواند هر دو را داشته باشد Gateway پشت لودبالانسر اصلی می‌نشیند و ترافیک ورودی را مدیریت می‌کند و  Mesh در لایه پایین‌تر، بین سرویس‌ها، امنیت و مشاهده‌پذیری را تأمین می‌کند.آیا می‌توان از API Gateway به جای Service Mesh استفاده کرد؟برای سیستم‌های بزرگ با صدها سرویس که نیاز به رمزگذاری داخلی، قطع‌کننده مدار، و انتشار قناری دارند خیر، زیرا API Gatewayبرای ترافیک ورودی بهینه شده و قرار دادن تمام منطق ارتباط بین سرویس‌ها در آن، آن را به یک گلوگاه و نقطه شکست تبدیل می‌کند.عوارض استفاده نکردن از Service Mesh چیست؟اول، امنیت ارتباط بین سرویس‌ها به جای mTLS خودکار، به تنظیم دستی گواهی‌ها وابسته است که به شدت خطاپذیر است. دوم، مشاهده‌پذیری ترافیک داخلی محدود است و اشکال‌زدایی مشکلات بین سرویس‌ها سخت می‌شود. سوم، پیاده‌سازی الگوهایی مانند قطع‌کننده مدار و انتشار قناری به صورت دستی در هر سرویس، کد تکراری و مستعد باگ ایجاد می‌کند. همچنین، تغییر در زیرساخت شبکه (مثل اضافه کردن رمزگذاری) نیاز به تغییر در تک تک سرویس‌ها دارد.منابعLevine, I. (2020). Idit Levine on Gloo, Service Mesh Interface, and WebAssembly Hub. InfoQ Podcast. Solo.io. (n.d.). Gloo Edge documentation. Service Mesh Interface (SMI). (n.d.). SMI specification. ایستگاه هشتم : Command Query Responsibility Segregationنگاهی به عملکرد Command Query Responsibility Segregationمفهوم Command Query Responsibility Segregationحتماً برایتان پیش آمده که در یک سیستم، تعداد درخواست‌های خواندن چندین برابر درخواست‌های نوشتن است. مثلاً در یک فروشگاه آنلاین، هزاران کاربر محصولات را می‌بینند، اما تعداد سفارش‌های جدید شاید در همان لحظه فقط ده تا باشد. اگر از یک مدل داده واحد برای هر دو استفاده کنید، درخواست‌های سنگین خواندن، سرعت نوشتن را پایین می‌آورند و برعکس این موضوع هم صادق است.CQRS  جدا کردن مدل نوشتن از مدل خواندن است. مدل Command مسئول تغییر وضعیت است مانند ایجاد سفارش جدید و از اصول Domain Driven Design پیروی می‌کند. مدل Query فقط برای نمایش داده بهینه شده و می‌تواند از یک دیتابیس کاملاً متفاوت مثل Elasticsearch  استفاده کند.پروژه Mixter که به چندین زبان پیاده شده، یک نمونه عملی از CQRS در کنار Event Sourcing است.باید توجه داشت که این جداسازی هزینه دارد: همگام‌سازی بین دو مدل نیاز به رویدادها یا پیام‌های غیرهمگام دارد.عوارض استفاده از CQRS چیست؟اول، افزایش پیچیدگی کد و معماری. دوم، تأخیر در همگام‌سازی بین مدل خواندن و نوشتن سوم، نیاز به زیرساخت پیام‌رسان برای انتقال رویدادها بین دو مدل. همچنین، تیم باید با دو مدل داده جداگانه کار کند که درک و دیباگ کردن سیستم را سخت‌تر می‌کند.اگر شما یک سیستم ساده‌ای می‌نویسید که نرخ خواندن و نوشتن به هم نزدیک است، و منطق دامین پیچیدگی خاصی ندارد، CQRS را فراموش کنید. هزینه جداسازی مدل‌ها، همگام‌سازی بین آنها، و پیچیدگی ذهنی که به تیم تحمیل می‌کند، از هر سودی بیشتر است.منابعMixter Project. (n.d.). CQRS and Event Sourcing in multiple languages. GitCode. Fowler, M. (2011). CQRS. MartinFowler.com. Microsoft Learn. (n.d.). CQRS pattern. ایستگاه نهم : Event-Driven Architectureنگاهی به معماری Event-Drivenمفهوم Event-Driven Architectureحتماً برایتان پیش آمده که در یک سیستم، سرویس A باید با سرویس B حرف بزند. در معماری سنتی، A مستقیم B را صدا می‌زند و منتظر می‌ماند. اگر B پایین باشد، A هم مختل می‌شود. اگر B کند باشد، A هم کند می‌شود. این همان معماری درخواست-پاسخ همگام است.معماری رویدادمحور این گره را باز می‌کند. درEDA، سرویس A به جای صدا زدن مستقیمB، یک رویداد منتشر می‌کند (مثلاً «سفارش جدید ثبت شد») و کارش تمام است. هر سرویسی که به این رویداد علاقه داشته باشد (پرداخت، انبار، ایمیل) آن را دریافت و پردازش می‌کند. تولیدکننده از مصرف‌کنندگان خبر ندارد و مصرف‌کننده‌ها هم از یکدیگر بی‌خبرند.سه فناوری رایج در این حوزه نقش‌های متفاوتی دارند. Kafka  برای رویدادهای بلندمدت مناسب است (مثل تاریخچه ثبت‌نام کاربران) و پیام را برای همیشه نگه می‌دارد. RabbitMQ  برای فرمان‌ها و تسک‌ها بهینه است (مثل ارسال ایمیل) و پیام را پس از تحویل حذف می‌کند. gRPC برای تماس‌های همگام با تأخیر پایین (مثل اعتبارسنجی سریع) استفاده می‌شود. در یک سیستم واقعی، هر سه می‌توانند کنار هم کار کنند.باید توجه داشت که EDA شل‌شدگی و مقیاس‌پذیری می‌آورد، اما هزینه‌اش پیچیدگی دیباگ کردن است. وقتی یک رویداد چندین سرویس را زنجیره‌وار تحریک می‌کند، فهمیدن اینکه «چرا این اتفاق نیفتاد» ساعتها وقت می‌برد. منابعJava Code Geeks. (2021). Polyglot Event-Driven Systems with Kafka, RabbitMQ and gRPC. Retrieved from https://www.javacodegeeks.com/2021/03/polyglot-event-driven-systems-with-kafka-rabbitmq-and-grpc.htmlMotia Framework. (n.d.). Event-driven step-based architecture. Retrieved from https://motia.devTNGlobal. (2024). Why Event-Driven Architecture is crucial for Agentic AI. Retrieved from https://tnGlobal.com ایستگاه دهم : Serverless Architectureمفهوم Serverless Architectureحتماً برایتان پیش آمده که برای اجرای یک تابع ساده، مجبورید یک سرور کامل راه‌اندازی کنید، سیستم عامل نصب کنید، و نگران مقیاس‌پذیری و در دسترس بودن آن باشید. Serverless فراموش کردن همه این دغدغه‌ها است. شما فقط کدتان را می‌دهید، بقیه با ارائه‌دهنده ابراست.Serverless بر دو پایه اصلی استوار است :Function as a Service مثل AWS Lambda که واحد اجرا یک تابع است.Backend as a Service مثل دیتابیس‌های مدیریت‌شده است.باید توجه داشت که Serverless به معنای نبودن سرور نیست. سرور همیشه هست، اما مدیریت آن به طور کامل بر عهده ارائه‌دهنده ابر است. همچنین هر تابع به طور مستقل مقیاس می‌شود. اگر تابع پردازش تصویر صد برابر شود، تابع احراز هویت تحت تأثیر قرار نمی‌گیرد.یک راهنمای عملی از Pulumi نشان می‌دهد که یکی از جذابیت‌های سرورلس، توانایی ترکیب زبان‌های مختلف در یک پروژه است. مثلاً می‌توانی یک تابع به زبان پایتون برای پردازش داده سنگین بنویسی، یک تابع به زبان Go برای API با کارایی بالا، و یک تابع TypeScript برای هندل کردن webhookها اما هر تابع به طور مستقل scale می‌شود. اگر ترافیک تابع پایتون صد برابر شود، روی تابع Go هیچ تأثیری نمی‌گذارد. هزینه هم فقط به ازای زمان اجرا و تعداد فراخوانی محاسبه می‌شود. برای توابعی که گاهی هفته‌ها فراخوانی نمی‌شوند، این مدل قیمت‌گذاری فوق‌العاده به صرفه است. نکته دیگر اینکه آدرس HTTPS هر تابع در طول به‌روزرسانی‌ها ثابت می‌ماند و نیازی به تغییر در سمت کلاینت نیست.هشدار: آیا سرورلس برای همه workloadها مناسب است؟اگر برنامه شما همیشه روشن است و ترافیک ثابتی دارد، هزینه Serverless ممکن است از یک سرور سنتی بیشتر شود. همچنین cold start (تأخیر راه‌اندازی تابع پس از چند دقیقه بیکاری) می‌تواند برای برنامه‌های حساس به تأخیر کشنده باشد.عوارض استفاده از سرورلس چیست؟cold start تأخیر قابل توجهی به پاسخ اضافه می‌کند. وابستگی شدید به ارائه‌دهنده ابر و قفل شدن در آن.  رخ می‌دهد. دیباگ کردن توابع توزیع‌شده سخت‌تر از یک برنامه monolithic است. همچنین، محدودیت‌هایی در زمان اجرا (معمولاً ۱۵ دقیقه) و حافظه وجود دارد که همه workloadها را پشتیبانی نمی‌کند.منابعPulumi. (n.d.). Deploy multi-language serverless functions on Google Cloud. Retrieved from https://www.pulumi.com/docs/guides/crosswalk/gcp/serverless/Amazon Web Services. (n.d.). AWS Lambda documentation. Retrieved from https://docs.aws.amazon.com/lambda/ Serverless Architecture. Retrieved from https://developer.baidu.comایستگاه یازدهم : API-first Approachمفهوم API-first Approachحتماً برایتان پیش آمده که تیم فرانت‌اند و بک‌اند همزمان کار می‌کنند، اما وقتی زمان یکپارچه‌سازی می‌رسد، می‌بینند APIهایی که هرکدام ساخته‌اند با هم جور درنمی‌آید. API-first یعنی قبل از نوشتن هر کدی، اول مشخصات API را با استانداردی مثل OpenAPI (Swagger) طراحی و مستند کنید. همه تیم‌ها روی آن توافق می‌کنند و بعد کدشان را می‌نویسند.تیم Algolia که خدمات جستجو ارائه می‌دهد، با این روش توانسته، ده API و یازده زبان برنامه‌نویسی را با سه مهندس نگهداری کند. به این صورت: از روی مشخصات OpenAPI، هشتاد درصد کد SDKها به صورت خودکار تولید می‌شود. خط لوله تولید تا انتشار در npm، PyPI و Maven حدود ۲۰ دقیقه طول می‌کشد.از نظر منAPI-first بیش از یک رویکرد فنی، یک قرارداد اجتماعی بین تیم‌هاست. می‌گوید: ما اول توافق می‌کنیم چطور حرف بزنیم، بعد هر کد می‌رویم کدمان را می‌نویسیم. بدون این توافق، دو تیم موازی ممکن است هفته‌ها کار کنند و آخر سر ببینند APIهایشان با هم جور درنمی‌آید.آیا می‌توان بدون API-first کار کرد؟ برای یک تیم کوچک و یک پروژه ساده، بله اما برای چندین تیم که روی سرویس‌های مختلف کار می‌کنند، دیر یا زود به تضاد و دوباره‌کاری می‌رسید.عوارض استفاده نکردن از API-first چیست؟اول، دوباره‌کاری و اتلاف وقت در یکپارچه‌سازی. دوم، مستندات قدیمی و بی‌اعتبار که با کد همخوانی ندارد. سوم، وابستگی تیم‌ها به هم که پیشرفت را کند می‌کند. همچنین، تولید SDK برای زبان‌های مختلف به صورت دستی غیرممکن می‌شود.منابعAlgolia Engineering. (2021). How we generate 100+ SDKs. OpenAPI Initiative. (n.d.). OpenAPI Specification (Swagger).Anthropic. (2024). Model Context Protocol (MCP).  ایستگاه دوازدهم :  Domain Driven Designمفهوم Domain Driven Designحتماً برایتان پیش آمده که یک تیم توسعه و متخصصان کسب‌وکار از یک واژه معنای متفاوتی می‌فهمند. مثلاً «مشتری» برای تیم فنی یک رکورد در دیتابیس است، اما برای تیم فروش معنای پیچیده‌تری دارد. این اختلاف زبان، ریشه بسیاری از پروژه‌های شکست‌خورده است.اریک ایوانز در کتاب معروفش (Blue Book) راه‌حلی به نام Domain Driven Design ارائه کرد. ایده مرکزی به این صورت است که: تیم توسعه باید با متخصصان دامین بنشیند و یک مدل مشترک از کسب‌وکار بسازد. این مدل به یک زبان یکپارچه تبدیل می‌شود که هم در جلسات و هم در کد استفاده می‌شود.باید توجه داشت که DDD برای سیستم‌هایی با منطق کسب‌وکار پیچیده مثل بیمه و مالی طراحی شده، نه برای فرم‌های ساده ثبت‌نام.هشدار: آیا هر پروژه‌ای به DDD نیاز دارد؟برای سیستم‌های ساده مثل یک وبلاگ یا فروشگاه کوچک، DDD وزن اضافه است. پیاده‌سازی Aggregate و Repository و Value Object بدون داشتن منطق پیچیده، فقط کدزنی بی‌نتیجه است و باعث پیچیدگی بیشتر کد و نیاز به حضور دائمی متخصص دامین در کنار تیم توسعه دارد. منابعEvans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.Vernon, V. (2013). Implementing Domain-Driven Design. Addison-Wesley.Fowler, M. (n.d.). Domain Driven Design. MartinFowler.com. ایستگاه سیزدهم : Hexagonal Architectureمفهوم Hexagonal Architectureحتماً برایتان پیش آمده که یک تغییر ساده در پایگاه داده یا سرویس خارجی، کل برنامه را تحت تأثیر قرار می‌دهد. مثلاً وقتی می‌خواهید از MySQL به PostgreSQL مهاجرت کنید، باید لایه business را هم تغییر دهید. مشکل از جایی است که لایه‌ها به ترتیب به هم وابسته‌اند. این وابستگی باعث می‌شود تست کردن لایه business بدون پایگاه داده واقعی سخت شود و تغییر یک فناوری مثل عوض کردن دیتابیس از SQL به NoSQL کل برنامه را تحت تأثیر قرار دهد.معماری هگزاگونال که Ports & Adapters هم نامیده می‌شود این وابستگی را برعکس می‌کند. لایه دامین یا منطق کسب‌وکار در مرکز قرار می‌گیرد و هیچ دانشی از دنیای خارج ندارد. ارتباط با خارج، تنها از طریق پورت interface تعریف می‌شود. «اداپتورها» کار تبدیل را انجام می‌دهند. مثلاً اداپتور REST درخواست HTTP را به فراخوانی متد مناسب تبدیل می‌کند. اداپتور دیتابیس پیاده‌سازی خاص ذخیره‌سازی را فراهم می‌کند.نکته جالب این است که: برای تست کردن دامین، فقط کافی است یک اداپتور تست بنویسید که به جای دیتابیس واقعی، داده را در حافظه ذخیره کند. برای تغییر دیتابیس هم فقط یک اداپتور جدید می‌نویسید؛ لایه دامین اصلاً عوض نمی‌شود.باید توجه داشت که اسم «هگزاگونال» قراردادی است و ربطی به شش ضلع ندارد. می‌تواند سه پورت یا نه پورت داشته باشد. اصل این است که وابستگی‌ها به سمت داخل اشاره می‌کنند.هشدار: آیا معماری هگزاگونال برای همه پروژه‌ها مناسب است؟اگر پروژه‌تان ساده است و احتمال تغییر زیرساخت در آینده نزدیک وجود ندارد، لایه‌بندی اضافه فقط زمان توسعه را می‌برد. این معماری برای سیستم‌هایی با طول عمر بالا و نیاز به تست‌پذیری زیاد ارزش دارد. در غیر این صورت، تعداد کلاس‌ها و فایل‌ها افزایش می‌یابد،درک جریان داده برای تازه‌واردها سخت‌تر است و برای پروژه‌های خیلی کوچک، زمان توسعه را افزایش می‌دهد. همچنین، ممکن است تیم حس کند برای کاری ساده، پیچیدگی زیادی ساخته است.منابعCockburn, A. (2005). Hexagonal Architecture. AlistairCockburn.us. Hombergs, T. (2018). Get Your Hands Dirty on Clean Architecture. Leanpub.Graca, H. (n.d.). Hexagonal Architecture. HerbertoGraca.com.  ایستگاه چهاردهم : Event Sourcingمفهوم Event Sourcingبه جای ذخیره وضعیت فعلی یک شیء، تمام اتفاقاتی که برای آن شیء افتاده را ذخیره کن!فرض کنید بخواهید بدانید که یک سفارش در طول زمان چه تغییراتی کرده است. در دیتابیس معمولی، فقط وضعیت فعلی را دارید برای حل این مشکل چه راهکاری دارید؟Event Sourcing این مشکل را حل می‌کند. به جای ذخیره وضعیت فعلی، تمام اتفاقاتی که برای یک شیء افتاده را ذخیره می‌کند. به طور مثال برای یک حساب بانکی تمامی تغییرات و تاریخچه شی ذخیره میشود: «حساب با ۱۰۰۰ تومان افتتاح شد»، «۵۰۰ تومان برداشت شد»، «۲۰۰ تومان واریز شد».وضعیت فعلی شی از بازپخش این رویدادها به دست می‌آید.با این راهکار تاریخچه کامل و قابلیت ممیزی در دسترس شماست. می‌توانید سیستم را در هر لحظه از گذشته بازسازی کنید.برای جلوگیری از بازپخش طولانی، از «اسنپ‌شات» (ذخیره وضعیت هر چند وقت یکبار) استفاده می‌شود.باید توجه داشت که Event Sourcing اغلب با CQRS ترکیب می‌شود. رویدادها از Aggregate خارج و منتشر می‌شوند و مدل Query جداگانه از آنها Viewهای خود را می‌سازد.Event Sourcing  یک فناوری نیست، یک تعهد است. وقتی رویدادها را ذخیره کردید، دیگر نمی‌توانید به راحتی ساختارشان را عوض کنید. هر تغییر در schema رویدادها باید backward compatible باشد یا migration بنویسید. اگر نیازی به تاریخچه و ممیزی ندارید، Event Sourcing فقط پیچیدگی اضافه می‌کند. وقتی رویدادها را ذخیره کردید، تغییر ساختارشان بسیار سخت است و نیاز به migration دارد. منابعFowler, M. (2005). Event Sourcing. MartinFowler.com.Young, G. (n.d.). Event Sourcing. CodeBetter. Mixter Project. (n.d.). CQRS and Event Sourcing implementation. GitCode. ایستگاه پانزدهم : Low-code/No-code platformsمفهوم Low-code/No-code platformsحتماً برایتان پیش آمده که یک ایده ساده برای یک ابزار داخلی شرکت داشته‌اید، اما پیاده‌سازی آن با کدنویسی سنتی چند هفته زمان می‌برد. سکوهای Low-code و No-code این مشکل را حل می‌کنند. با کشیدن و رها کردن کامپوننت‌ها و تعریف جریان کاری می‌توانید در عرض چند روز یک اپلیکیشن کاربردی بسازید.سکوی Low-code و No-code به کاربران اجازه می‌دهند برنامه بسازند بدون اینکه خطی کد بنویسند یا با کمترین کدنویسی ممکن برانامه خود را بسازند. برای روشن شدن موضوع، به مثال DOML نگاه کنیم. در مقاله علمیDOML، محققان یک زبان مدل‌سازی به نام DOML طراحی کرده‌اند که یک لایه Low-code روی Infrastructure as Code است. یعنی کاربر که ممکن است متخصص زیرساخت نباشد می‌تواند با یک زبان ساده توصیف کند که اپلیکیشنش چه زیرساختی نیاز دارد. این یعنی کاربر بدون دانستن جزئیات Terraform یا Ansible، می‌تواند زیرساختش را روی چندین پلتفرم مختلف Provision کند. تفاوت Low-code و No-code چیست؟تفاوت Low-code و No-code در مخاطب است. No-code برای "شهروندان توسعه‌دهنده" (افراد غیرفنی مثل تحلیلگران کسب‌وکار) طراحی شده و هیچ راهی برای خروج از جعبه ندارد. Low-code برای توسعه‌دهندگان حرفه‌ای طراحی شده و امکان نوشتن کد سفارشی برای سناریوهای پیچیده را می‌دهد. نقطه ضعف اصلی هر دوی این سکوها وابستگی به فروشنده (Vendor Lock-in) است. وقتی برنامه‌ات روی یک پلتفرم Low-code خاص ساخته شد، بیرون آوردن آن به سختی ممکن است. سرویس‌هایی مثل OutSystems، Mendix و Power Apps در این حوزه فعال هستند.این سکوها برای MVP و ابزارهای داخلی عالی هستند.برای محصول اصلی یک شرکت فناوری چطور؟تجربه نشان داده است که دیر یا زود به مرز سکو برخورد می‌کنید یعنی چیزی که سکو نمی‌تواند انجام دهد شما را گرفتار می‌کند. منابعWurster, M., et al. (2021). DOML: A new modeling approach for Infrastructure as Code. ScienceDirect.OutSystems. (n.d.). Low-code platform documentation. Mendix. (n.d.). Low-code platform.   ایستگاه شانزدهم : Business Process Management Systemsفرایند مدیریت کسب و کارمفهوم Business Process Management Systemsحتماً برایتان پیش آمده که یک فرآیند کسب‌وکار مثل «ثبت سفارش تا تحویل» را بررسی کرده‌اید. این فرآیند ممکن است ده‌ها مرحله داشته باشد از تأیید اعتبار مشتری، چک کردن موجودی، تخصیص به انباردار، بسته‌بندی، ارسال تا پیامک به مشتری است. اگر بخواهید این را با کدنویسی سنتی پیاده کنید، خیلی زود درگیر پیچیدگی حالت‌های مختلف می‌شوید: اگر موجودی نبود چه؟ اگر مشتری پولش را پس گرفت چه؟BPMS با زبان استاندارد BPMN 2.0 این پیچیدگی را مدیریت می‌کند. فرآیند به صورت گرافیکی مدل می‌شود. تسک‌ها دو نوع هستند: تسک انسانی مثلاً «مدیر تأیید کند» و تسک خودکار مثلاً «وضعیت سفارش را به‌روز کن») موتور BPMS مثل Camunda، jBPM، مدل را اجرا و وضعیت هر نمونه را پیگیری می‌کند. وقتی یک تسک انسانی به پایان رسید، موتور به صورت خودکار مرحله بعد را شروع می‌کند. از دید معماری سازمانی، BPMS یک نقطه مرکزی برای دیده‌شدن و بهینه‌سازی فرآیندهای بین‌سیستمی است. داشبوردهای BPMS نشان می‌دهند کدام مرحله گلوگاه شده، کدام کارمند بیشترین تسک را انجام داده، و چقدر از SLAها عقب هستیم. BPMSهای مدرن با معماری رویدادمحور و سرورلس ترکیب می‌شوند تا فرآیندهای مقیاس‌پذیر بسازند.باید توجه داشت که BPMS زمانی می‌درخشد که فرآیندها مدام تغییر می‌کنند. اگر هر ماه یک مرحله جدید به گردش کار اضافه می‌شود، با BPMS فقط مدل را عوض می‌کنید، بدون اینکه نیاز به deploy دوباره کل نرم‌افزار باشد.عوارض استفاده از BPMS چیست؟اول، هزینه بالای پیاده‌سازی اولیه و خرید لایسنس (مخصوصاً نسخه‌های سازمانی). دوم، نیاز به تخصص در BPMN و موتورهای مربوطه. سوم، برای فرآیندهای بسیار ساده، BPMS وزن اضافه است. همچنین، ممکن است موتور BPMS برای سناریوهای با توان عملیاتی بسیار بالا (مثل میلیون‌ها درخواست در ثانیه) گلوگاه شود. منابعCamunda. (n.d.). BPMN 2.0 Engine documentation. jBPM. (n.d.). jBPM documentation. Red Hat. OMG. (2011). Business Process Model and Notation (BPMN) Version 2.0.   ایستگاه هفدهم : Message Queue (Kafka, RabbitMQ)مفهوم Message Queue (Kafka, RabbitMQ)Message Queue یک صف ارتباطی بین سرویس‌هاست. سرویس A پیام را در صف می‌گذارد و بدون اینکه منتظر بماند به کار خود ادامه می‌دهد. سرویس B یا چند سرویس وقتی وقت داشت می‌آید پیام را از صف برمی‌دارد و پردازش می‌کند. در معماری‌های مبتنی بر میکروسرویس، Message Queue یک مؤلفه کلیدی است. اما همه Message Queueها یکسان نیستند. دو نمونه بسیار محبوب، RabbitMQ و Apache Kafka، تفاوت‌های بنیادی دارند.یک مقاله عملی از Java Code Geeks این تفاوت را شفاف توضیح داده است RabbitMQ یک صف سنتی است. پیام را از صف حذف می‌کند بعد از اینکه مصرف‌کننده آن را دریافت کرد. برای سناریوهایی که "پیام دقیقاً یک بار پردازش شود" مهم است، مثل دستورات (commands) و تسک‌ها، مناسب است. در مقابل، Kafka یک commit log است. پیام‌ها را برای همیشه یا برای مدت مشخصی نگه می‌دارد و مصرف‌کننده تعیین می‌کند از کجا شروع به خواندن کند. یعنی می‌توانی یک پیام را چند بار بخوانی. برای رویدادهایی که "چه شد" مهم است و تاریخچه کامل آن ارزش دارد، مناسب است. در یک سیستم polyglot، اغلب هر دو را کنار هم می‌بینند: Kafka برای رویدادهایی مثل تاریخچه کاربران، چون می‌خواهی تاریخچه ثبت نام همه کاربران را داشته باشی وRabbitMQ برای فرمان‌هایی مثل ارسال ایمیل چون می‌خواهی ایمیل دقیقاً یک بار فرستاده شود.باید توجه داشت که انتخاب اشتباه بین این دو هزینه بالایی دارد. کافکا مثل کامیون است؛ اگر فقط می‌خواهید یک پاکت نامه بفرستید، راه‌اندازی کامیون بیهوده است RabbitMQ برای بسیاری از موارد نه فقط کافی، بلکه بهینه‌تر است. هشدار: آیا می‌توان بدون Message Queue کار کرد؟برای سیستم‌های خیلی ساده با تعداد سرویس کم، بله اما به محض اینکه بیش از ۳ سرویس داشته باشید که باید غیرهمگام با هم ارتباط برقرار کنند، Message Queue تبدیل به یک ضرورت می‌شود. منابعJava Code Geeks. (2021). Polyglot Event-Driven Systems with Kafka, RabbitMQ and gRPC. Apache Kafka. (n.d.). Documentation. RabbitMQ. (n.d.). Documentation.   ایستگاه هجدهم : Containers (Docker) , Container Orchestration (Kubernetes)مفهوم Containers , Container Orchestrationحتماً برایتان پیش آمده که یک برنامه روی دستگاه شما کار می‌کند، اما روی دستگاه همکارتان از کار می‌افتد. مشکل وابستگی‌هاست. کتابخانه‌ای که شما دارید، او ندارد یا نسخه‌اش فرق می‌کند. کانتینرها این مشکل را حل می‌کنند. برنامه و همه وابستگی‌هایش در یک بسته قابل حمل به اسم Image جمع می‌شود. هر جا که Docker نصب باشد، Image دقیقاً یکسان اجرا می‌شود.تفاوت کانتینر با ماشین مجازی در این است که کانتینرها هسته سیستم‌عامل میزبان را به اشتراک می‌گذارند. نتیجه: کانتینرها در کسری از ثانیه بالا می‌آیند (در مقابل VM چند دقیقه  زمان می‌برد.حالا فرض کنید صدها کانتینر دارید. چه کسی تصمیم می‌گیرد هر کدام روی کدام سرور برود؟ اگر کانتینری خراب شد، چه کسی دوباره راه‌اندازی‌اش کند؟ اگر ترافیک بالا رفت، چه کسی تعداد کانتینرها را زیاد کند؟ اینجاست که Kubernetes وارد می‌شود Kubernetes یک ارکستراتور کانتینر است که تمام این کارها را خودکار می‌کند: زمان‌بندی، خودترمیمی، مقیاس خودکار، rolling update بدون قطعی، و سرویس‌دیسکاوری.باید توجه داشت که Kubernetes یک راه‌حل جادویی نیست. اگر فقط یک اپلیکیشن ساده روی یک سرور دارید، Kubernetes یعنی پیچیدگی بیش از حد و همین یک سرور با systemd و یک binary کافی است.هشدار: آیا هر برنامه‌ای به کانتینر و Kubernetes نیاز دارد؟برای تیم‌های کوچک با کمتر از ۵ سرویس، کانتینر ممکن است مفید باشد اما Kubernetes تقریباً همیشه زیاد است. Kubernetes زمانی معنا پیدا می‌کند که تیم شما بیش از ۵ نفر است، بیش از ۱۰ سرویس دارید، و نیاز به استقرار مکرر و مقیاس خودکار دارید. منابعDocker. (n.d.). Docker documentation. Kubernetes. (n.d.). Kubernetes documentation. Wurster, M., et al. (2021). DOML: A new modeling approach for Infrastructure as Code. ScienceDirect. ایستگاه نوزدهم :  Multi-Tenancy Architectureمفهوم Multi-Tenancy Architectureحتماً از جیمیل استفاده کرده‌اید. میلیاردها کاربر از یک برنامه واحد استفاده می‌کنند، اما هرکس فقط ایمیل‌های خودش را می‌بیند. این همان معماری (Multi-Tenancy) است: یک نمونه از نرم‌افزار به چندین مشتری سرویس می‌دهد و داده‌ها کاملاً از هم جدا می‌مانند.سه سطح اصلی برای پیاده‌سازی وجود دارد:دیتابیس جداگانه برای هر مشتری: بالاترین ایزوله‌سازی، اما تعداد دیتابیس‌ها زیاد می‌شودو هزینه بالا می‌رود.اسکیماهای جداگانه در یک دیتابیس مشترک:در این سرای ایزوله‌سازی خوب و هزینه متوسط است اما مدیریت backup پیچیده‌تر است.  یک اسکیما با فیلدtenant_id: بالاترین بهره‌وری از منابع اما سخت‌ترین پیاده‌سازی را دارد هر کوئری باید شامل tenant_id باشد تا کسی به داده دیگری دسترسی پیدا نکند.باید توجه داشت که انتخاب سطح multi-tenancy یکی از اولین و مهم‌ترین تصمیم‌ها در طراحی یک SaaS است. این تصمیم غیرقابل برگشت است؛ مهاجرت از دیتابیس جدا به اسکیماهای مشترک بسیار سخت و پرریسک است.آیا می‌توان از یک دیتابیس مشترک بدون فیلد tenant_id استفاده کرد؟فقط برای یک مستأجر، برای چند مستأجر،دیر یا زود داده‌ها قاطی می‌شوند و جداسازی آنها غیرممکن می‌گردد.عوارض انتخاب سطح نامناسب چیست؟اول، اگر ایزوله‌سازی را خیلی بالا بگیرید، هزینه زیرساخت و نگهداری افزایش می‌یابد. دوم، اگر خیلی پایین بگیرید خطر نشت داده بین مستأجرها به دلیل خطای برنامه‌نویسی وجود دارد. سوم، مهاجرت بین سطوح بسیار دشوار و زمان‌بر است. همچنین، پشتیبان‌گیری و بازیابی داده در سطوح مختلف پیچیدگی متفاوتی دارد. منابعMicrosoft Learn. (n.d.). Multi-tenant architecture patterns.AWS SaaS Factory. (n.d.). Multi-tenant patterns. Fowler, M. (n.d.). Multi-Tenancy. MartinFowler.com. ایستگاه بیستم : Data Migrationمفهوم Data Migrationحتماً برایتان پیش آمده که بخواهید دیتابیس خود را از Oracle به PostgreSQL منتقل کنید، یا معماری برنامه را از monolithic به microservices تغییر دهید. در هر دو حالت، باید داده‌ها را از یک سیستم به سیستم دیگر منتقل کنید. این همان Data Migration است.فرآیند مهاجرت داده پنج مرحله اصلی دارد:کشف و پروفایل: ببینید چه داده‌ای دارید و کیفیت آن چطور است؟طراحی هدف: مدل داده جدید را مشخص کنید. توسعه: کدهای ETL بنویسید Extract, Transform, Loadتست: بررسی کنید همه داده درست منتقل شده باشد.اجرا: مرحله نهایی برش اجرا است.چالش‌های اصلی شامل داده‌های ناسازگار مثل فرمت‌های مختلف آدرس، زمان از کار افتادگی در حینcutover، و حفظ یکپارچگی ارجاعی بین جداول است.ابزارهایی مثل Liquibase و Flyway برای مهاجرت ساختار دیتابیس در طول زمان محبوب هستند همچنین AWS DMSو Azure Database Migration Service برای مهاجرت‌های ابری مناسب است. جالب اینجاست که Event Sourcing می‌تواند مهاجرت را ساده کند به صورتی که  اگر داده به صورت رویداد ذخیره شده باشد، کافی است رویدادها را در دیتابیس جدید بازپخش کنید تا وضعیت نهایی ساخته شود.باید توجه داشت که آزمایش در محیط production در مهاجرت داده، یک فاجعه است. تیم‌های حرفه‌ای معمولاً مهاجرت را سه بار تمرین می‌کنند (dry-run) قبل از اینکه بار چهارم اجرای واقعی را انجام دهند.هشدار!آیا می‌توان مهاجرت را بدون cutover انجام داد؟در الگوی dual-write، همزمان در دیتابیس قدیم و جدید نوشته می‌شود. ابتدا داده‌های تاریخی منتقل می‌شود، سپس برنامه به صورت همزمان در هر دو می‌نویسد، و بعد از اطمینان از هماهنگی، خواندن هم به دیتابیس جدید منتقل می‌شود. این روش downtime را به حداقل می‌رساند اما پیچیدگی بیشتری دارد.عوارض مهاجرت داده چیست؟اول، خطر از دست رفتن داده یا خراب شدن یکپارچگی ارجاعی دارد. دوما، زمان از کار افتادگی (downtime) در روش‌های ساده است. منابعMicrosoft Learn. (n.d.). Data migration overview. AWS Database Migration Service. (n.d.). DMS documentation. Liquibase. (n.d.). Database migration tool. Fowler, M. (n.d.). Data Migration Patterns. MartinFowler.com. مهسا دباغیانمهسا دباغیانSun, 31 May 2026 19:10:25 +0330