https://virgool.ir/feed/@a.otrydfa2026-11-11 05:02:30https://files.virgool.ir/upload/users/4887721/avatar/SDyx0j.pnghttps://virgool.ir/@a.otrydhttps://virgool.ir/@a.otryd/معماری-نرم-افزار-در-عصر-low-code-و-no-code-آیا-آینده-توسعه-نرم-افزار-بدون-کدنویسی-است-gwdixdtdiqq5در دهه‌های گذشته، توسعه نرم‌افزار همواره به مهارت‌های برنامه‌نویسی و تیم‌های فنی وابسته بوده است. اما با افزایش سرعت تحول دیجیتال و نیاز سازمان‌ها به تولید سریع‌تر سامانه‌های نرم‌افزاری، رویکردهای جدیدی برای توسعه نرم‌افزار شکل گرفته‌اند. یکی از مهم‌ترین این رویکردها، استفاده از پلتفرم‌های Low-Code و No-Code است. این فناوری‌ها وعده می‌دهند که فرآیند توسعه نرم‌افزار را ساده‌تر، سریع‌تر و در دسترس‌تر کنند؛ اما سؤال مهم این است که این پلتفرم‌ها از دیدگاه معماری نرم‌افزار چگونه عمل می‌کنند و چه تأثیری بر آینده طراحی سیستم‌های نرم‌افزاری خواهند داشت؟Low-Code و No-Code چیست؟پلتفرم‌های Low-Code محیط‌هایی هستند که بخش عمده توسعه نرم‌افزار را از طریق ابزارهای بصری، کامپوننت‌های آماده و مدل‌های از پیش طراحی‌شده انجام می‌دهند و تنها در برخی قسمت‌ها نیاز به کدنویسی محدود وجود دارد. در مقابل، پلتفرم‌های No-Code به گونه‌ای طراحی شده‌اند که کاربران حتی بدون دانش برنامه‌نویسی نیز بتوانند نرم‌افزارهای کاربردی ایجاد کنند.در نگاه اول ممکن است این فناوری‌ها تنها ابزاری برای افزایش سرعت توسعه به نظر برسند؛ اما واقعیت این است که آن‌ها نوع جدیدی از تفکر معماری را وارد صنعت نرم‌افزار کرده‌اند. در این رویکرد، تمرکز از «نوشتن کد» به «مدل‌سازی و طراحی سیستم» منتقل می‌شود!!معماری در قلب پلتفرم‌های Low-Codeبسیاری از افراد تصور می‌کنند که استفاده از Low-Code به معنای حذف معماری نرم‌افزار است، در حالی که واقعیت دقیقاً برعکس است. هرچه میزان کدنویسی کمتر شود، اهمیت معماری بیشتر خواهد شد. دلیل این موضوع آن است که تصمیمات معماری تعیین می‌کنند سیستم چگونه توسعه پیدا کند، چگونه با سایر سامانه‌ها ارتباط برقرار کند و چگونه در آینده نگهداری شود.اغلب پلتفرم‌های Low-Code از معماری‌های مدرن مانند Microservices، Service-Oriented Architecture (SOA) و API-Driven Architecture استفاده می‌کنند. در این ساختارها، قابلیت‌های مختلف سیستم به سرویس‌های مستقل تقسیم می‌شوند و از طریق API با یکدیگر تعامل دارند. این موضوع باعث می‌شود توسعه، نگهداری و گسترش سیستم ساده‌تر شود.همچنین اکثر این پلتفرم‌ها بر بستر رایانش ابری توسعه یافته‌اند و از الگوهای Cloud-Native استفاده می‌کنند. به همین دلیل، مقیاس‌پذیری، دسترس‌پذیری و انعطاف‌پذیری بالاتری نسبت به بسیاری از سامانه‌های سنتی دارند.مزایای معماری Low-Codeمهم‌ترین مزیت این رویکرد، کاهش زمان توسعه است. بسیاری از قابلیت‌هایی که در گذشته نیازمند صدها یا هزاران خط کد بودند، اکنون از طریق ابزارهای بصری و اجزای آماده قابل پیاده‌سازی هستند. این موضوع باعث می‌شود سازمان‌ها بتوانند سریع‌تر به تغییرات بازار و نیازهای کسب‌وکار پاسخ دهند.مزیت دیگر، افزایش مشارکت ذی‌نفعان کسب‌وکار در فرآیند توسعه است. در توسعه سنتی، فاصله قابل توجهی بین تیم فنی و کاربران نهایی وجود داشت؛ اما در پلتفرم‌های Low-Code این فاصله کاهش یافته و کارشناسان کسب‌وکار نیز می‌توانند در طراحی فرآیندها و حتی توسعه سامانه مشارکت داشته باشند.از منظر معماری نرم‌افزار، استفاده از کامپوننت‌های استاندارد، معماری ماژولار و قابلیت یکپارچه‌سازی بالا نیز از جمله نقاط قوت این فناوری محسوب می‌شوند.چالش‌ها و محدودیت‌هابا وجود مزایای متعدد، پلتفرم‌های Low-Code راه‌حل جادویی برای همه پروژه‌ها نیستند. یکی از مهم‌ترین چالش‌های آن‌ها وابستگی به ارائه‌دهنده پلتفرم یا Vendor Lock-in است. در بسیاری از موارد، انتقال یک سامانه از یک پلتفرم به پلتفرم دیگر بسیار دشوار و پرهزینه خواهد بود.علاوه بر این، در پروژه‌های پیچیده و سازمانی که نیاز به سفارشی‌سازی گسترده دارند، محدودیت‌های این پلتفرم‌ها آشکار می‌شود. برخی تصمیمات معماری توسط خود پلتفرم اتخاذ می‌شوند و توسعه‌دهنده کنترل کاملی بر ساختار داخلی سیستم ندارد. این مسئله می‌تواند بر امنیت، عملکرد و انعطاف‌پذیری بلندمدت سیستم تأثیر بگذارد.همچنین در سامانه‌های حساس، بلادرنگ (Real-Time) یا دارای حجم پردازش بالا، توسعه سنتی هنوز در بسیاری از موارد گزینه مناسب‌تری محسوب می‌شود.جمع‌بندیبررسی انجام‌شده نشان می‌دهد که Low-Code و No-Code صرفاً ابزارهایی برای کاهش حجم کدنویسی نیستند؛ بلکه نمایانگر تغییری اساسی در شیوه طراحی و توسعه نرم‌افزار هستند. این پلتفرم‌ها با تکیه بر معماری‌های مدرن، توسعه سریع‌تر و مشارکت بیشتر کاربران را امکان‌پذیر کرده‌اند و به همین دلیل نقش مهمی در تحول دیجیتال سازمان‌ها ایفا می‌کنند.با این حال، انتخاب این فناوری‌ها باید بر اساس نیازهای معماری پروژه انجام شود. معمار نرم‌افزار باید علاوه بر مزایای توسعه سریع، عواملی مانند امنیت، مقیاس‌پذیری، قابلیت نگهداری، یکپارچه‌سازی و وابستگی به پلتفرم را نیز در نظر بگیرد. در نهایت، می‌توان گفت آینده توسعه نرم‌افزار نه در حذف معماری، بلکه در اهمیت بیشتر آن نهفته است؛ زیرا هرچه ابزارهای توسعه ساده‌تر شوند، تصمیمات معماری نقش تعیین‌کننده‌تری در موفقیت سیستم‌ها خواهند داشت.منابعRichardson, C. Microservices Patterns: With Examples in Java. Manning Publications, 2018.Bass, L., Clements, P., Kazman, R. Software Architecture in Practice (4th Edition). Addison-Wesley, 2021.Mendix Low-Code Guide.Gartner Research Reports on Low-Code Application Platforms.     IEEE Software & ACM Digital Library articles related to Low-Code/No-Code Platforms and Software Architecture.اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است.#معماري_نرم_افزار_بهشتيAbolfazl OmidiyanAbolfazl OmidiyanWed, 05 Aug 2026 01:12:30 +0330https://virgool.ir/@a.otryd/hi-shb7xbaseybc1- Master Software Architecture: From Simplicity to Complexityسخنران: Maciej «MJ» Jedrzejewskiاین سخنرانی چالش‌های مربوط به رشد و تغییر سیستم‌های نرم‌افزاری رو بررسی می‌کنه و نشون میده که چطور یه سیستم از حالت ساده اولیه به مرور زمان به یه ساختار پیچیده تبدیل میشه. نکته خیلی مهمی که سخنران بهش اشاره می‌کنه بحث بار شناختی یا همون Cognitive Load هست که روی دوش تیم توسعه و معماران سیستم قرار می‌گیره. وقتی ویژگی‌های جدید به نرم‌افزار اضافه میشه سیستم‌ها معمولا به سمت توزیع‌شده شدن می‌رن و اگه این فرآیند درست مدیریت نشه معماری سیستم به شدت آسیب می‌بینه و به اصطلاح تبدیل به یه توده بی‌شکل یا Big Ball of Mud میشه.برداشت من اینه که پیچیدگی به خودی خود چیز منفی یا اشتباهی نیست بلکه نشونه پیشرفت و توسعه سیستم هست اما مشکل زمانی پیش میاد که ساختارهای ما پویا نباشن و نتونن خودشون رو با این تغییرات هماهنگ کنن. به عنوان دانشجوی این رشته فکر می‌کنم این ارایه به خوبی روشن می‌کنه که معماران نرم‌افزار نباید تصمیم‌های خشک و غیرقابل تغییر بگیرن بلکه باید مرزهای ساختاری سیستم رو طوری طراحی کنن که با تغییر بار کاری یا تغییرات زیرساختی کل سیستم به هم نریزه و فرآیند توسعه کند نشه. این ویدیو دید خیلی خوبی درباره طراحی سیستم‌های توزیع‌شده پایدار به ما میده.2- Platforms: Build Abstractions, Not Illusionsسخنران: Gregor Hohpeتوی این سخنرانی گرگور هوپ که از نویسنده‌های معروف حوزه تفکر معماری هست روی مبحث پلتفرم‌ها و رایانش ابری دست میذاره. اون تفاوت خیلی قشنگی بین انتزاع یا همون Abstraction و توهم یا Illusion تعریف می‌کنه. حرف اصلیش اینه که ما پلتفرم‌ها رو می‌سازیم تا پیچیدگی‌های زیرساخت رو از دید توسعه‌دهنده‌ها مخفی کنیم اما اگه این کار رو جوری انجام بدیم که واقعیت‌های شبکه و سخت‌افزار کاملا نادیده گرفته بشه در واقع یه توهم خطرناک ساختیم که موقع ترافیک بالا یا خرابی‌ها رفتارهای پیش‌بینی‌نشده‌ای از خودش نشون میده.به نظر من این ارایه برای کسانی که روی لایه‌بندی قابلیتهای فناوری اطلاعات کار می‌کنن یه زنگ خطر هست. معمار سیستم نباید ارتباطش با لایه فنی و عملیاتی قطع بشه. پلتفرم‌های توزیع‌شده زمانی موفق هستن که به جای حذف کامل جزئیات ابزارهای پایش و مدیریت بهینه رو در اختیار لایه‌های بالاتر بذارن تا سیستم بتونه در شرایط بحرانی خودش رو حفظ کنه.3- Software Architecture for Tomorrow: Expert Talkسخنرانان: Sam Newman & Julian Woodاین ویدیو یه گفتگوی عالی بین سم نیومن که از پیشگامان بحث میکروسرویس‌ها هست و جولیان وود هست که آینده معماری نرم‌افزار رو بررسی می‌کنن. تمرکز اصلی اونا روی تقابل الگوهای ارتباطی همگام و ناهمگام یا همون Event-Driven هست. اونا نشون میدن که چطور سیستم‌های مدرن برای داشتن انعطاف بیشتر و اتصال ضعیف‌تر بین اجزا باید به سمت رویدادمحوری حرکت کنن.برداشت من اینه که با وجود ورود ابزارهای مبتنی بر هوش مصنوعی به فرآیند توسعه باز هم تفکر استراتژیک معماری غیرقابل جایگزین هست. توی سیستم‌های بزرگ سازمانی مشخص کردن مرزهای دامنه و نحوه توزیع داده‌ها نیاز به درک عمیق از بیزینس داره. این سخنرانی به ما یاد میده که آینده این رشته در گرو ترکیب هوشمندانه سیستم‌های واکنش‌گرا و فناوری‌های نوظهور هست بدون اینکه اسیر موج‌های موقتی بازار بشیم.4-Facilitating Software Architectureسخنرانان: Andrew Harmel-Law & Sonya Natanzonاین ارایه بیشتر روی جنبه‌های انسانی و فرآیندی معماری تمرکز داره و اون نگاه سنتی که معمار رو یه تصمیم‌گیرنده مطلق و جدا از تیم‌ها می‌دونست رد می‌کنه. سخنران‌ها مدل جدیدی از حاکمیت معماری رو معرفی می‌کنن که بر پایه مشارکت و تمرکززدایی هست یعنی تصمیمات باید نزدیک‌ترین فاصله رو به تیم‌های محصول داشته باشن.نکته کاربردی این سخنرانی معرفی ابزارهایی مثل مستندسازی تصمیمات معماری یا همون ADR هست. از دید من مستندات نباید یه کار تشریفاتی باشن که بعد از تموم شدن پروژه نوشته میشن بلکه باید یه فرآیند زنده و روزمره باشن. وقتی تصمیم‌ها با دلایل فنی و محدودیت‌هاشون به صورت شفاف ثبت بشن دانش فنی سازمان حفظ میشه و سیستم می‌تونه به صورت ارگانیک و بدون وابستگی به افراد خاص تکامل پیدا کنه.5- Modern Enterprise Architecture: Architecting for Outcomesسخنران: Simon Rohrerسایمون رورر توی این سخنرانی به نقد چارچوب‌های صلب و سنتی معماری سازمانی می‌پردازه که معمولا وقت زیادی رو صرف مستندسازی‌های طولانی و مدل‌های استاتیک می‌کنن که قبل از کامل شدن منقضی میشن. اون در عوض رویکرد نتیجه‌محور یا Outcome-Driven و ترکیب تفکر سیستمی با اصول دواپس رو پیشنهاد میده.برداشت تحلیلی من اینه که معماری نباید یه هدف ثابت باشه بلکه باید توانمندکننده جریان ارزش در سازمان باشه. توی یه ساختار مدرن لایه‌های کسب‌وکار و آی‌تی نباید از هم جدا باشن. معماری مرجع باید طوری طراحی بشه که انطباق‌پذیر باشه و بتونه تغییرات سریع بازار رو تحمل کنه. این ویدیو نگاه ما رو به تکامل همزمان استراتژی سازمان و سیستم‌های نرم‌افزاری ارتقا میده.منابع:[1] https://www.youtube.com/watch?v=ZCrCqbblXjk[2] https://www.youtube.com/watch?v=mRoWGqcBSzk[3] https://www.youtube.com/watch?v=8KntBPOdfWA[4] https://www.youtube.com/watch?v=YpFR8qzwYSA[5] https://www.youtube.com/watch?v=UMaZ-O2KRCwاين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است.#معماري_نرم_افزار_بهشتيAbolfazl OmidiyanAbolfazl OmidiyanSat, 11 Jul 2026 23:43:41 +0330https://virgool.ir/@a.otryd/some-topics-from-software-architecture-io4ozbycdug1Chaos Engineeringما همیشه سعی می‌کنیم سیستمی بسازیم که خراب نشود اما بیایید واقع‌بین باشیم؛ سیستم‌ها بلاخره یک‌جایی می‌لنگند!در مهندسی آشوب ما عمداً در محیط عملیاتی، اختلال ایجاد می‌کنیم (مثلاً قطع کردن یک دیتابیس یا ایجاد تأخیر در شبکه هدف این نیست که سیستم را بترکانیم، بلکه می‌خواهیم ببینیم سیستم در برابر خطاها چقدر تاب‌آور است. این کار کمک می‌کند نقاط ضعف پنهان را قبل از اینکه کاربر متوجه شود، پیدا کنیم. BFFقبلاً برای وب و موبایل از یک API یکسان استفاده می‌کردیم که دردسرساز بود. وب‌سایت کلی دیتا می‌خواست و موبایل فقط یک بخش کوچک. در الگوی BFF، ما برای هر رابط کاربری یک لایه بک‌اند اختصاصی داریم این‌طوری هر کلاینت دقیقاً همان دیتایی را می‌گیرد که نیاز دارد. این الگو باعث می‌شود تیم‌های فرانت‌اند و بک‌اند کمتر با هم درگیر شوند و سرعت توسعه خیلی بالاتر برود.    AI4SEاین همان بخشی است که زندگی ما دانشجوها را راحت کرده. از «گیت‌هاب کوپایلوت» گرفته تا ابزارهایی که باگ‌های کد را پیدا می‌کنند یا تست می‌نویسند. اینجا هوش مصنوعی نقش یک دستیار حرفه‌ای را دارد که کارهای تکراری و خسته‌کننده (مثل داکیومنت‌نویسی یا کدنویسی‌های تکراری) را انجام می‌دهد تا ما بتوانیم روی طراحی سیستم و منطق بیزینس تمرکز کنیم. SE4AIاینجا قضیه برعکس است؛ یعنی چطور یک مدل هوش مصنوعی را داخل یک پروژه بزرگ بگنجانیم؟ برخلاف کدهای سنتی، مدل‌های هوش مصنوعی «احتمالاتی» هستند و با داده تغییر می‌کنند. مدیریت این مدل‌ها نیاز به زیرساخت خاص دارد؛ چون باید نسخه مدل، کیفیت داده‌ها و مانیتورینگ خروجی را دائماً کنترل کنیم تا مدل در طول زمان دچار افت کیفیت نشود.MLOpsهمان DevOps برای پروژه‌های یادگیری ماشین است. یک مدل وقتی روی لپ‌تاپ دانشمند داده خوب کار می‌کند، دلیل نمی‌شود در سرور هم عالی باشد MLOps کمک می‌کند که مدل‌ها به صورت خودکار آموزش ببینند، تست شوند و در محیط عملیاتی مستقر شوند. اگر دقت مدل در طول زمان کم شد، MLOps کمک می‌کند که دوباره مدل آموزش ببیند و جایگزین شود.IaCدیگر کسی سرور را دستی کانفیگ نمی‌کند! با ابزارهایی مثل Terraform، ما کل زیرساخت را در قالب کد می‌نویسیم. مزیتش این است که اگر سرورها از بین رفتند، با یک دستور کل زیرساخت را در جای دیگری بالا می‌آوریم. این کار باعث می‌شود محیط توسعه و محیط واقعی دقیقاً یکسان باشند و دیگر از بهانه‌هایی مثل «روی سیستم من کار می‌کرد» خبری نباشد. API Gateway & Service Meshدر میکروسرویس‌ها، مدیریت ارتباطات کابوس است. API Gateway مثل «لابی هتل» است؛ تمام درخواست‌های بیرونی اول می‌آیند اینجا، تأیید هویت می‌شوند و بعد به سمت سرویس مربوطه می‌روند. اما Service Mesh مثل Istio برای ارتباطات داخلی بین سرویس‌هاست؛ کارهایی مثل رمزنگاری و مدیریت خطا را انجام می‌دهد تا خود میکروسرویس‌ها درگیر پیچیدگی‌های شبکه نشوند. CQRSخیلی وقت‌ها فشار روی دیتابیس برای خواندن و نوشتن هم‌زمان، سیستم را کند می‌کند. در CQRS می‌گوییم بیایید مدل نوشتن را از مدل خواندن جدا کنیم. برای نوشتن از یک دیتابیسِ امن استفاده می‌کنیم و برای خواندن، داده‌ها را در یک مدلِ سریع کپی می‌کنیم. این کار مقیاس‌پذیری سیستم را به شدت بالا می‌برد.EDAدر سیستم‌های سنتی، همه منتظر پاسخ بقیه هستند. در EDA سرویس‌ها با «رویداد» با هم حرف می‌زنند. مثلاً سرویس سفارش فقط می‌گوید «سفارش ثبت شد» و کارش تمام می‌شود. سرویس‌های انبار و ایمیل این رویداد را می‌شنوند و واکنش نشان می‌دهند. این یعنی سرویس‌ها کاملاً از هم مستقل هستند و اگر یکی قطع شود، کل سیستم نمی‌خوابد. Serverlessدر سرورلس، ما اصلاً درگیر سرور نمی‌شویم. فقط کد  خود را می‌فرستیم و اجرا می‌کنیم. هزینه‌اش هم فقط برای زمانی است که کد در حال اجراست. عالی است چون لازم نیست نگران سخت‌افزار باشیم، فقط باید حواسمان به محدودیت‌های زمانی تابع باشد. برای پروژه‌هایی که ترافیکشان نوسانی است، انتخاب اول است. API-firstقبل از زدن حتی یک خط کد، باید قرارداد API را بنویسیم. این کار باعث می‌شود تیم‌های مختلف فرانت و بک همزمان کار کنند، چون می‌دانند ورودی و خروجی‌ها چیست. وقتی این قرارداد مثل Swagger مشخص باشد، احتمال سوءتفاهم بین تیم‌ها تقریباً صفر می‌شود. DDDDDD  برای پروژه‌های بزرگ است که منطق بیزینس پیچیده‌ای دارند. به جای تمرکز روی دیتابیس، روی مفاهیم بیزینس تمرکز می‌کنیم. ما سیستم را به «بخش‌های کوچک تقسیم می‌کنیم که هر کدام زبان مخصوص به خود را دارند. این روش باعث می‌شود کد ما با منطق کسب‌وکار همسو باشد و با تغییرات بیزینس، کد به هم نریزد. Hexagonalاین معماری می‌گوید: منطق اصلی برنامه نباید به دیتابیس یا وب یا فریم‌ورک وابسته باشد. منطق برنامه در مرکز است و از طریق درگاه‌ها با دنیای بیرون در ارتباط است.اگر فردا بخواهیم دیتابیس را عوض کنیم یا وب‌سایت را تبدیل به اپلیکیشن موبایل کنیم، منطق برنامه هیچ تغییری نمی‌کند! این یعنی کدی که خیلی راحت تست می‌شود. Event Sourcingبه جای ذخیره وضعیتِ نهایی، ما تمام رویدادهای منجر به این وضعیت را ذخیره می‌کنیم مثلاً ثبت واریز، برداشت، واریز این یعنی ما همیشه تاریخچه داریم و می‌توانیم در هر لحظه وضعیت سیستم را دوباره بازسازی کنیم. برای سیستم‌های بانکی که حسابرسی دقیق نیاز دارند، این روش بی‌نظیر است.Low-code/No-codeاین ابزارها برای وقتی‌اند که می‌خواهیم سریع یک ایده یا ابزار داخلی را پیاده کنیم. با درگ‌ودراپ کردنِ المان‌ها، محصول نهایی ساخته می‌شود. برای استارتاپ‌ها که زمان ندارند، عالی استاما خب، برای سیستم‌های خیلی پیچیده و خاص، دست ما را می‌بندند و کدنویسیِ دستی همیشه انعطاف بیشتری دارد.BPMSتوی سازمان‌های بزرگ، فرآیندهایی مثل تایید مرخصی یا تایید وام مراحل زیادی دارند. به جای هاردکد کردن این‌ها، از BPMS استفاده می‌کنیم تا نمودار فرآیند را بکشیم اگر فردا مدیر شرکت گفت باید یک مرحله اضافه شود  فقط نمودار را تغییر می‌دهیم و تمام! Kafka & RabbitMQوقتی دیتابیس زیر فشار ترافیکِ بالا در حال انفجار است، از صف پیام استفاده می‌کنیم. پیام‌ها در صف می‌مانند تا سرویس مربوطه با سرعتِ خودش آن‌ها را بردارد و پردازش کند کافکا در مقیاس‌های غول‌آسا عالی است و رابیت برای کارهای تراکنشی سریع. این‌ها باعث می‌شوند سیستم ما در برابر ترافیک بالا ناپایدار نشود. Docker & Kubernetesداکر یعنی بسته‌بندی کد با تمام پیش‌نیازها. کوبرنتیز هم مدیرِ این بسته‌هاست؛ اگر کانتینری کرش کرد، خودش دوباره می‌سازدش؛ اگر ترافیک زیاد شد، کانتینرهای بیشتری بالا می‌آورد. بدون این‌ها، مدیریت سیستم‌های ابری امروزی غیرممکن است. معماری چند-مستأجریدر سایت‌های SaaS، یک نسخه از نرم‌افزار به ۱۰۰ تا مشتری سرویس می‌دهد. چالش اصلی این است که داده‌های هر مشتری باید کاملاً از بقیه جدا باشد .طراحی درست این معماری باعث می‌شود با کمترین هزینه زیرساخت، به بیشترین مشتری سرویس بدهیم. مهاجرت دادهمهاجرت داده یعنی تعویض موتور هواپیما در حال پرواز! باید دیتابیس قدیمی را به جدید منتقل کنیم بدون اینکه سرویس برای لحظه‌ای قطع شود.این کار نیاز به برنامه‌ریزی دقیق، تست‌های مکرر و استراتژی بازگشت دارد تا مبادا دیتای مشتری حین انتقال بپرد. Abolfazl OmidiyanAbolfazl OmidiyanTue, 02 Jun 2026 18:35:21 +0330