1- مهندسی آشوب - Chaos Engineering
مهندسی آشوب یک رویکرد جذاب و در عین حال عجیب در توسعه نرمافزار است. درواقع ما میآییم و به جای اینکه صبر کنیم تا سیستم در دنیای واقعی خراب شود، خودمان به صورت عمدی و کنترلشده در سیستم خرابی ایجاد میکنیم. هدف این است که نقاط ضعف سیستم را قبل از اینکه در محیط عملیاتی و برای کاربران نهایی مشکلساز شوند، کشف کنیم.
برای مثال فرض کنید شرکتی مثل نتفلیکس برای اطمینان از اینکه قطع شدن یک سرور باعث توقف پخش فیلمها نمیشود، ابزاری میسازد که به صورت تصادفی سرورهایش را خاموش میکند. این کار به تیمها کمک میکند تا سیستمهایی تابآورتر یا به اصطلاح Resilient بسازند. اگر بخواهیم تشبیه کنیم در واقع مهندسی آشوب شبیه به واکسن زدن است؛ ما یک ویروس ضعیفشده را به سیستم تزریق میکنیم تا سیستم ایمنی آن در برابر حملات و قطعیهای بزرگتر مقاوم شود.
2- بکاند برای فرانتاند - Backend for Frontend – BFF
در معماریهای جدید، کلاینتها و کاربران مختلفی مثل اپلیکیشن موبایل، وبسایت و ساعتهای هوشمند داریم. هر کدام از این رابطهای کاربری، نیازهای متفاوتی به دادهها دارند. الگوی BFF پیشنهاد میدهد که به جای داشتن یک بکاند غولپیکر و عمومی برای همه، برای هر فرانتاند یک بکاند اختصاصی و کوچک بسازیم. این بکاند که بهش بکاند واسط هم میگن، دقیقا همان دادههایی را جمعآوری و بهینهسازی میکند که فرانتاند مربوطهاش نیاز دارد. این کار باعث میشود کدهای سمت فرانتاند سبکتر بمانند، ترافیک شبکه بهینه شود و تیمهای توسعهدهنده بتوانند با استقلال بیشتری روی برخی محصولات خود مثل اندروید کار کنند، بدون اینکه تغییراتشان روی نسخه وب تاثیر منفی بگذارد.
3- هوش مصنوعی برای مهندسی نرمافزار - AI4SE
این مفهوم به معنای استفاده از ابزارهای هوش مصنوعی برای بهبود، سریعتر کردن و بهینهسازی فرآیند مهندسی نرمافزار است. اینروزا هوش مصنوعی دیگه فقط یک محصول نهایی نیست، بلکه تبدیل به دستیار برنامهنویسان شده. ابزارهایی مثل GitHub Copilot یا سیستمهای تولید خودکار تست نرمافزار، نمونههای بارز AI4SE هستند. با استفاده از این رویکرد، کارهای تکراری مثل نوشتن کدهای پایه، کشف باگها، و حتی مستندسازی کدها به هوش مصنوعی سپرده میشود. در نتیجه، برنامهنویسان میتوانند تمرکز خود را روی حل مسائل پیچیدهتر و طراحی معماریهای بهینهتر بگذارند. این فناوری نهتنها سرعت توسعه را بالا میبرد، بلکه با شناسایی زودهنگام خطاها، کیفیت نهایی نرمافزار را نیز به شکل چشمگیری افزایش میدهد.
4- مهندسی نرمافزار برای هوش مصنوعی - SE4AI
در بخش قبل گفتیم که AI4SE درباره کمک هوش مصنوعی به برنامهنویسی است، SE4AI دقیقاً برعکس آن عمل میکند؛ یعنی چگونه از اصول مهندسی نرمافزار برای ساخت و مدیریت سیستمهای هوش مصنوعی استفاده کنیم.
مدلهای یادگیری ماشین به خودی خود فقط مدلهای ریاضی و آماری هستند، اما برای اینکه این مدلها به یک محصول قابل اعتماد تجاری تبدیل شوند، نیاز به معماری درست، تستپذیری، کنترل نسخه و نگهداری مداوم دارند. در برنامهنویسی سنتی، رفتار سیستم قطعی است، اما در هوش مصنوعی رفتار سیستم بر اساس دادهها تغییر میکند. پس SE4AI تلاش میکند با ارائه چارچوبها و استانداردهای مهندسی، توسعه سیستمهای مبتنی بر هوش مصنوعی را قابل پیشبینی، امن و پایدارتر کند.
5- عملیات یادگیری ماشین - MLOps
کلمه MLOps از ترکیب دو کلمه Machine Learning و DevOps بوجود آمده است. وقتی یک مهندس داده مدل هوش مصنوعی خوبی روی کامپیوتر خودش میسازد، کار تمام نشده است؛ این مدل باید روی سرورها قرار بگیرد، به صورت مداوم با دادههای جدید آموزش ببیند و عملکرد آن بررسی بشود. MLOps مجموعهای از روندها و ابزارهاست که هدف آن استقرار و نگهداری یکپارچه و خودکار مدلهای یادگیری ماشین در محیط عملیاتی است.
این رویکرد کمک میکند تا فاصله بین تیمهای هوش مصنوعی و تیمهای زیرساخت از بین برود. با MLOps، مدلها سریعتر به دست کاربر نهایی میرسند، بهروزرسانی آنها خودکار میشود و در صورت افت دقت مدل، سیستم بلافاصله هشدار میدهد.
6- زیرساخت به عنوان کد - Infrastructure as Code - IaC
در گذشته، برای راهاندازی یک سرور جدید، مهندسان شبکه باید به صورت دستی سیستمعامل نصب میکردند، پورتها را باز میکردند و نرمافزارها را پیکربندی میکردند. این کار بسیار زمانبر و دارای خطای انسانی بود. زیرساخت به عنوان کد یا همان IaC راهکاری است که در آن تمام نیازمندیهای زیرساختی مثل سرورها، شبکهها و دیتابیسها در قالب کدهای متنی قابل خواندن نوشته میشوند. ابزارهایی مثل Terraform این کدها را میخوانند و زیرساخت را به صورت کاملاً خودکار در سرورهای ابری میسازند.
بزرگترین مزیت IaC این است که میتوانیم تنظیمات سرور خود را مانند کدهای برنامهنویسی، کنترل نسخه کنیم و بارها آن را بدون تغییر و با اطمینان در محیطهای مختلف اجرا کنیم.
7- درگاه API و شبکه سرویس - API Gateway & Service Mesh
در معماری مایکروسرویس، سیستم از دهها یا صدها سرویس کوچک و مستقل تشکیل شده است.
API Gateway مثل یک دربان یا پذیرشگر یک هتل عمل میکند؛ تمام درخواستهای کاربران خارجی اول به این درگاه میرسند و بعد درگاه تصمیم میگیره که هر درخواست را به کدام سرویس داخلی بفرسته و همچنین کارهایی مثل احراز هویت را هم انجام میدهد.
اما Service Mesh بیشتر شبیه سیستم ارتباطی داخلی کارمندان هتل است. وقتی سرویسهای داخلی میخواهند با هم صحبت کنند، شبکه سرویس ارتباطات بین آنها را مدیریت، رمزنگاری و مانیتور میکند. ترکیب این دو مفهوم به مهندسان کمک میکند تا ترافیک خارجی و داخلی سیستم را با بالاترین امنیت و بدون پیچیده کردن کدهای اصلی مدیریت کنند.
8- جداسازی مسئولیت خواندن و نوشتن - CQRS
الگوی CQRS یک ایده ساده اما بسیار قدرتمند را بیان میکند و آن این است که در بسیاری از سیستمهای نرمافزاری، تعداد دفعاتی که اطلاعات را میخوانیم بسیار بیشتر از دفعاتی است که اطلاعات را تغییر میدهیم یا اضافه میکنیم. پس چرا باید هر دو کار توسط یک دیتابیس یا یک مدل پردازشی انجام شود؟
در این معماری، مسیر خواندن دادهها یا همان کوئری از مسیر نوشتن آنها یا همان کامند، کاملاً جدا میشود. ما میتوانیم برای نوشتن اطلاعات از یک دیتابیس ایمن با قفلهای قوی استفاده کنیم، اما برای خواندن، دادهها را در یک دیتابیس فوقسریع و کششده قرار دهیم. این کار عملکرد سیستمهایی با ترافیک خواندن بالا مثل شبکههای اجتماعی یا فروشگاهها را به شدت بهبود میبخشه.
9- معماری رویدادمحور - Event-Driven Architecture - EDA
معماری رویدادمحور، سبکی از طراحی سیستم است که در آن اجزای نرمافزار بر اساس زمان وقوع رویدادها با هم تعامل میکنند، نه بر اساس درخواستهای مستقیم و همگام.
برای مثال فرض کنید در یک فروشگاه اینترنتی خرید میکنید؛ به جای اینکه سیستم ثبت سفارش منتظر بماند تا با سیستم انبارداری هماهنگ کند، صرفاً یک پیام صادر میکند که یک سفارش جدید ثبت شد. حالا هر سرویسی که به این موضوع نیاز داشته باشد مثل سرویس انبارداری، صدور فاکتور یا درگاه پرداخت، این پیام را دریافت کرده و کار خودش را مستقل انجام میدهد. این معماری وابستگی سیستمها به یکدیگر را کاهش داده و آنها را در برابر ترافیکهای ناگهانی، مقیاسپذیرتر میکند.
10- معماری بدون سرور - Serverless Architecture
معماری بدون سرور به این معنی نیست که اصلاً سختافزار یا سروری وجود ندارد، بلکه به این معناست که برنامهنویس دیگر هیچ دغدغهای بابت مدیریت، نگهداری، آپدیت سیستمعامل یا افزایش منابع سرورها ندارد و تمام این وظایف بر عهده یک ارائهدهنده خدمات ابری مثل AWS یا برخی سرویسهای ابری داخلی است. توسعهدهنده فقط کدهای منطقی خود را مینویسد و روی پلتفرم آپلود میکند.
جذابترین ویژگی Serverless مدل قیمتگذاری آن است؛ ما فقط به همان اندازه که کدمان در حال اجراست هزینه پرداخت میکنیم، نه برای سروری که ۲۴ ساعته روشن است. این روش هزینههای استارتاپها را به شدت کاهش داده و سرعت استقرار نرمافزار را بالا میبرد.
11- رویکرد API-first
رویکرد API-first یک تغییر تفکر اساسی در روند توسعه محصول است. به طور سنتی، تیمها اول دیتابیس و منطق برنامه را مینوشتند و در آخر، برای وصل کردن آن به رابط کاربری، یک API طراحی میکردند. اما در رویکرد API-first، قبل از نوشتن حتی یک خط کد، اول قرارداد و ظاهر APIها با دقت طراحی و مستند میشود.
این کار باعث میشود تیمهای فرانتاند و بکاند بتوانند به صورت کاملاً موازی کار خودشون را شروع کنند. این رویکرد باعث میشود نرمافزار از همان روز اول مقیاسپذیرتر طراحی شود و قابلیت اتصال به سرویسهای شخص ثالث در آن بسیار سادهتر باشد.
12- طراحی دامنه محور - Domain Driven Design - DDD
طراحی دامنه محور یا DDD، رویکردی است که تلاش میکند زبان، ساختار و کد نرمافزار را دقیقاً با زبان و منطق کسبوکار واقعی مشتری هماهنگ کند.
مشکل بسیاری از پروژههایی که شکستخوردهاند، این است که برنامهنویسان با اصطلاحات فنی صحبت میکنند، در حالی که مدیران کسبوکار ادبیات خودشان را دارند. DDD مفهومی به نام زبان همهجا حاضر) را معرفی میکند که همه افراد پروژه باید از آن استفاده کنند.
در این رویکرد، معماری برنامه بر اساس بخشهای مختلف کسبوکار مدلسازی میشود نه صرفا بر اساس جدولهای دیتابیس. این روش برای توسعه سیستمهای بزرگ، پیچیده و سازمانی که منطق تجاری سنگینی دارند، یک ضرورت حیاتی محسوب میشود.
13- معماری شش ضلعی - Hexagonal Architecture
معماری شش ضلعی که به عنوان معماری پورتها و آداپتورها نیز شناخته میشود، معرفی شد تا گره خوردن منطق اصلی نرمافزار با تکنولوژیهای بیرونی را حل کند. در این معماری، هسته اصلی کسبوکار در مرکز سیستم و مثل یک شش ضلعی قرار میگیرد و کاملاً مستقل از دیتابیسها، رابطهای کاربری وب یا فریمورکها نوشته میشود.
هر چیزی در دنیای بیرون، صرفاً از طریق پورتها یا رابطهای تعریف شده و آداپتورها یا همان کدهای تبدیلکننده، با این هسته ارتباط برقرار میکنند. این یعنی اگر روزی بخواهیم دیتابیس خودمان را تغییر دهیم یا نرمافزار را از بستر وب به بستر موبایل ببریم، کدهای مرکزی دستنخورده باقی میمانند و فقط آداپتورهای بیرونی تغییر میکنند.
14- منبعسنجی رویداد - Event Sourcing
در دیتابیسهای قدیمی، ما معمولاً فقط آخرین وضعیت یک رکورد را ذخیره میکنیم؛ مثلاً موجودی حساب بانکی ما الان ۵ میلیون تومان است. اما در رویکرد Event Sourcing، به جای ذخیره وضعیت فعلی، تمام اتفاقاتی که باعث رسیدن به این وضعیت شدهاند را به صورت یک زنجیره متوالی ذخیره میکنیم مثل مثل دفتر کل حسابداری.
یعنی برای مثال ثبت میکنیم: ۱۰ میلیون واریز شد، ۳ میلیون برداشت شد و ۲ میلیون دیگر برداشت شد. با پردازش این رویدادها از اول تا آخر، موجودی حال حاضر محاسبه میشود. این روش امکانات بینظیری مثل قابلیت بازگشت دقیق به وضعیت سیستم در هر زمان از گذشته، حسابرسی صددرصدی و کشف ریشهای باگهای پیچیده را فراهم میکند.
15- پلتفرمهای Low-code و No-code
پلتفرمهای Low-code یا No-code، ابزارهایی هستند که به کاربران اجازه میدهند با حداقل برنامهنویسی یا حتی بدون نوشتن یک خط کد، و صرفاً با استفاده از رابطهای گرافیکی و کشیدن و رها کردن، نرمافزار بسازند.
پلتفرمهای No-code بیشتر برای مدیران و کاربران تجاری مناسباند تا فرآیندهای ساده خود را خودکار کنند. در مقابل، پلتفرمهای Low-code علاوه بر ابزارهای بصری، امکان نوشتن کدهای سفارشی را به توسعهدهندگان میدهند تا پروژههای پیچیدهتری خلق کنند. این ابزارها روند تولید نمونههای اولیه و دیجیتالی شدن سازمانها را به شدت تسریع کرده و وابستگی مدوام کسبوکارها به برنامهنویسان ارشد را برای کارهای تکراری کاهش دادهاند.
16- سیستمهای مدیریت فرآیند کسبوکار - BPMS
سیستمهای مدیریت فرآیندهای کسبوکار نرمافزارهایی هستند که برای طراحی، اجرا، پایش و بهینهسازی فرآیندهای روزمره یک سازمان استفاده میشوند. فرض کنید فرآیند تایید قرارداد در یک شرکت شامل چندین مرحله تاییدیه توسط واحدهای حقوقی، مالی و مدیریت است. به جای اینکه این کارها با کاغذ یا تماس تلفنی انجام شود، یک سیستم BPMS این جریان کاری را به صورت خودکار هدایت و پیگیری میکند.
این ابزارها با استفاده از استانداردهای گرافیکی به مدیران اجازه میدهند فرآیندها را رسم کنند. اجرایBPMS باعث شفافیت بیشتر وظایف، کاهش خطاهای انسانی، شناسایی گلوگاههای اتلاف وقت و افزایش راندمان کلی کارمندان در یک سازمان میشود.
17- صف پیام - Message Queue
صف پیام یا Message Queue زیرساختی است که سرویسهای مختلف نرمافزاری میتوانند پیامهای خود را به صورت غیرهمزمان در آن قرار دهند تا سرویسهای دیگر، به نوبت آنها را پردازش کنند. ابزارهایی مثل RabbitMQ یا Kafka دقیقاً همین کار را میکنند. برای مثال فکر کنید در یک وبسایت شلوغ ثبتنام میکنید؛ سیستم ثبتنام، پیام "ارسال پیامک تایید" را داخل صف میاندازد و بلافاصله صفحه خوشآمدگویی را به شما نشان میدهد.
حالا سرور پیامک هر زمان که منابع آزاد داشت، پیام را از صف برداشته و ارسال میکند. این معماری تضمین میکند که کند شدن یک بخش از سیستم، باعث توقف کل برنامه نشود و سیستم بتواند فشارهای ناگهانی کاربران را تحمل کند.
18- کانتینرها و ارکستراسیون - Containers & Container orchestration
کانتینرها مانند Docker فناوریهایی هستند که کد برنامه و تمام پیشنیازهای اجرایی آن را در یک بسته مستقل، سبک و قابل حمل قرار میدهند. کانتینرها مشکل معروف این برنامه روی کامپیوتر من کار میکند اما روی سرور خراب میشود را برای همیشه حل میکنند. اما وقتی یک برنامه بزرگ میشود و تعداد این کانتینرها به صدها عدد میرسد، مدیریت دستی آنها غیرممکن است.
اینجاست که ابزارهای ارکستراسیون مثل Kubernetes وارد عمل میشوند. کوبرنتیز مانند یک رهبر ارکستر عمل میکند؛ مراقب است کانتینرهای خراب را ریاستارت کند، ترافیک را بین آنها تقسیم کند و در ساعات شلوغی، تعداد آنها را به صورت خودکار افزایش دهد.
19- معماری چندمستاجره - Multi-Tenancy Architecture
معماری چندمستاجره یا همان Multi-Tenancy مدلی است که در آن یک نسخه واحد از نرمافزار روی سرور اجرا میشود، اما همزمان به چندین مشتری یا سازمان مختلف یا به اصطلاح مستاجرها، خدمات مستقل میدهد.اکثر سیستمهای نرمافزار به عنوان سرویس (SaaS) مثل جیمیل، ترلو یا سرویسهای حسابداری آنلاین ابری، از این مدل استفاده میکنند.
در این معماری، به جای اختصاص دادن یک دیتابیس و سرور مجزا به هر مشتری، همه از یک زیرساخت مشترک قدرت میگیرند، اما دادههای هر سازمان از طریق شناسههای خاص کاملاً ایزوله و امن میماند. این رویکرد بهروزرسانی سیستم را به شدت آسان کرده و هزینههای زیرساختی ارائهدهنده خدمات را به طرز چشمگیری کاهش میدهد.
20- مهاجرت دادهها - Data Migration
در واقع به فرآیند حساس و پیچیده انتقال اطلاعات از یک سیستم، دیتابیس یا فضای ذخیرهسازی قدیمی به یک زیرساخت جدید، مهاجرت دادهها گفته میشود. این اتفاق معمولاً زمانی رخ میدهد که یک شرکت قصد دارد نرمافزارهای فرسوده خود را بهروز کند یا سرورهای فیزیکی خود را به فضاهای ابری مدرن منتقل کند.
با اینکه مفهوم آن ساده به نظر میرسد، اما Data Migration یکی از پرریسکترین عملیاتهای فناوری اطلاعات است. مسائلی مانند تغییر فرمت دادهها در حین انتقال، حفظ جامعیت و امنیت اطلاعات، و جلوگیری از قطع شدن دسترسی کاربران به سیستم در طول فرآیند، نیازمند برنامهریزی بسیار دقیق، بکآپگیریهای چندلایه و تستهای مکرر پیش از اجرای نهایی است.
منابع و مراجع
1- مقالات آموزشی وبسایت GeeksforGeeks:
آشنایی با درگاه API (API Gateway)
معرفی کانتینرها و داکر (Containers & Docker)
آشنایی با صف پیام (Message Queues)
معماری بدون سرور (Serverless Architecture)
2- مستندات معماری مایکروسافت و آمازون:
الگوی بکاند برای فرانتاند (BFF) - مستندات مایکروسافت.
الگوی جداسازی مسئولیت خواندن و نوشتن (CQRS) - مستندات مایکروسافت
الگوی منبعسنجی رویداد (Event Sourcing) - مستندات مایکروسافت
معماری رویدادمحور (Event-Driven Architecture) - مستندات آمازون (AWS)
3- مقالات IBM و Red Hat:
زیرساخت به عنوان کد (IaC) - مقالات آموزشی Red Hat
عملیات یادگیری ماشین (MLOps) - مقالات آموزشی IBM
معماری چندمستاجره (Multi-Tenancy) - مقالات آموزشی IBM
4- دانشنامه ویکیپدیا Wikipedia:
مهندسی آشوب (Chaos Engineering)
طراحی دامنهمحور (Domain-Driven Design)
معماری ششضلعی (Hexagonal Architecture)
5- گفتگو با ابزارهای هوش مصنوعی:
Google Gemini: برای خلاصهسازی مقالات تخصصی، درک تفاوتهای ظریف بین مفاهیمی مانند AI4SE و SE4AI.
ChatGPT: برای همفکری جهت پیدا کردن مثالهای ملموس و دنیای واقعی مانند تشبیه مهندسی آشوب به واکسن یا مثال هتل برای درگاه API.