حسن احمدیان نیا
مهندسی آشوب برای پاسخ به این سؤال طراحی شده که آیا سیستم ما برای اتفاقات غیرمنتظره واکنش درستی نشان میدهد؟ . این روش شامل انجام آزمایش های کنترل شده (مانند خاموشی سرویس، ایجاد تأخیر، برگرداندن خطا، یا تغییر ناگهانی ترافیک) روی یک سیستم توزیع شده است. هدفش، ایجاد اعتماد به توانایی سیستم در تحمل شرایط آشفته است. فرآیند کار به این صورت است: ابتدا یک فرضیه میسازیم (مثلاً اگر یک سرویس از کار بیفتد کاربر خطا نمیبیند) سپس اختلال را در محیط واقعی یا شبیه سازی شده ایجاد میکنیم ، رفتار سیستم را بررسی میکنیم، فرضیه را تأیید یا رد میکنیم، مشکل را رفع میکنیم و این چرخه را تکرار میکنیم. معروف ترین نمونه ابزار Chaos Monkey در نتفلیکس است که بهطور تصادفی سرویسها را خاموش میکند تا تابآوری سیستم تضمین شود.
در معماری سنتی یک API واحد به همه کلاینت ها سرویس میدهد ولی مثلا نیاز های وب با موبایل متفاوت است ، وب میتواند داده حجیم دریافت کند اما موبایل به داده سبک و کم حجم نیاز دارد تا مصرف اینترنت و باتری را کاهش دهیم
Backend for Frontend یا BFF، الگویی است که در آن به ازای هر نوع کلاینت (وب، موبایل، تلویزیون و...) یک بک اند اختصاصی و مجزا طراحی میشود.. هر BFF دقیقاً میداند که کلاینت مربوط به خودش چه دادهای با چه فرمتی میخواهد، سپس دادههای لازم را از سرویسهای اصلی میگیرد، ترکیب و فیلتر میکند و پاسخ آماده برمیگرداند. از مزایایش میتوان به کاهش مصرف داده، افزایش سرعت، استقلال تیمها و سادگی کلاینت اشاره کرد. برخلاف API Gateway که وظایف زیرساختی (مانند احراز هویت و مسیریابی) دارد، BFF وظایف منطق بیزینسی و مخصوص همان کلاینت را بر عهده میگیرد.
AI4SE به معنای استفاده از هوش مصنوعی برای بهبود مهندسی نرمافزار است. از دیدگاه معماری نرمافزار، AI4SE میتواند در طراحی معماری هم نقش داشته باشد مثلاً پیشنهاد الگوی معماری مناسب (مانند میکروسرویس یا مانولیتیک) بر اساس نیازمندیها، تشخیص ناسازگاریها در معماری پیشنهادی، یا تحلیل تأثیر تغییرات بر ساختار کلی سیستم. کاربردهای دیگر AI4SE شامل تولید خودکار کد (مثل GitHub Copilot) ، تکمیل هوشمند کد، تولید تستکیس، تشخیص باگ، تحلیل لاگها و مستندسازی کدهای قدیمی است. مزایای کلیدی افزایش بهرهوری و کاهش خطاهای انسانی است. چالشهای اصلی شامل جعبه سیاه بودن مدلها (قابلیت توضیح پذیری پایین)، نگرانیهای امنیتی و محرمانگی دادهها، خطر سوگیری، و دقت غیرقطعی است
SE4AI یا مهندسی نرمافزار برای هوش مصنوعی، به کارگیری اصول و روشهای مهندسی نرمافزار در توسعه سیستمهای مبتنی بر AI است. هدف اصلی، ساختن سیستمهای AI ای است که قابل اعتماد، قابل تست، قابل نگهداری و مسئولیتپذیر باشند. حوزههای اصلی شامل مدیریت نسخه مدلها، تست و تأیید سیستمهای غیرقطعی، تضمین کیفیت داده، اخلاق و عدالت در AI، و قابلیت توضیحپذیری تصمیمات مدل است. تفاوت SE4AI با AI4SE در جهت تأثیرگذاری است: SE4AI یعنی استفاده از مهندسی نرمافزار برای ساخت AI بهتر، در حالی که AI4SE یعنی استفاده از AI برای بهبود فرآیندهای مهندسی نرمافزار. این دو مفهوم مکمل یکدیگرند.
MLOps یا Machine Learning Operations را میتوان مجموعهای از روشها، ابزارها و اصول مهندسی دانست که برای مدیریت چرخه عمر مدلهای یادگیری ماشین استفاده میشود. این مفهوم از ایده DevOps الهام گرفته شده است؛ یعنی همانطور که در DevOps فرایند توسعه و استقرار نرمافزارها تا حد زیادی خودکار و استاندارد شد، در حوزه هوش مصنوعی نیز نیاز به چنین رویکردی احساس شد. به نظر من اهمیت MLOps از اینجا مشخص میشود که سیستمهای یادگیری ماشین با نرمافزارهای معمولی تفاوت دارند. در نرمافزارهای سنتی معمولاً کد مستقیماً خروجی را تولید میکند، اما در یادگیری ماشین ابتدا داده و کد با هم ترکیب میشوند تا یک مدل ساخته شود و سپس آن مدل خروجی را تولید میکند. به همین دلیل مدیریت این مدلها کار سادهای نیست. MLOps فقط یک ابزار خاص نیست، بلکه یک رویکرد برای مدیریت بهتر سیستمهای هوشمند است. این رویکرد کمک میکند مدلها به صورت خودکار آموزش ببینند، تست شوند، در صورت نیاز بهروزرسانی شوند و عملکرد آنها به طور مداوم بررسی شود تا کیفیت سیستم حفظ شود.
IaC یعنی دیگر خبری از این نیست که یک نفر برود توی پنل ابری (مثل AWS یا Azure) و با کلیک کردن، یکی یکی سرور بسازد، شبکه راه بیندازد، بعد برود سراغ سرور بعدی. به جای این کار، ما همه چیز را به صورت کد مینویسیم. همه چیز در کد نوشته میشود و همه اعضای تیم از همان کد استفاده میکنند در نتیجه محیط توسعه، تست و پروداکشن یکی میشوند و خبری از باگهای «فقط توی پروداکشن» نیست.
یکی از مفاهیم مهم این حوزه Idempotency یا تکرارپذیری است. یعنی اگر یک فایل IaC را هرچند بار اجرا کنی، همان تعداد سرور ساخته نمیشود؛ فقط یک بار ساخته میشود. دفعات بعد که اجرا میکنی، ابزار چک میکند که آیا این سرور از قبل وجود داردیا خیر؟
در IaC دو روش اصلی داریم: اولی Declarative یا اعلامی که ما فقط میگوییک آخر کار میخواهم یک شبکه با این مشخصات داشته باشم و ابزار خودش میفهمد چه قدمهایی بردارد. روش دیگر Imperative یا دستوری است که تو قدم به قدم میگویی اول این کار را بکن، بعد آن کار را بکن. روش Declarative معمولاً امنتر و متداولتر است چون ابزار مواظب است کاری را دوبار انجام ندهد.
API Gateway و Service Mesh هر دو به بحث مدیریت ارتباطات در معماری میکروسرویس مربوط میشوند، اما جایگاه و وظیفه متفاوتی دارند.
API Gateway یک سرور یا سرویس است که به عنوان نقطه ورودی یکتا برای تمام درخواستهای کلاینتها به سیستم میکروسرویسی عمل میکند. کارهای اصلیاش شامل احراز هویت، مسیریابی درخواستها، محدودیت نرخ، و تبدیل پروتکل است.
در مقابل، Service Mesh یک لایه زیرساختی است که ارتباط بین خود میکروسرویسها را مدیریت میکند. معمولاً با استفاده از یک پروکسی سبک به اسم sidecare در کنار هر سرویس اجرا میشود و کارهایی مثل سرویس دیسکاوری، تعادل بار، رمزنگاری ترافیک داخلی را انجام میدهد.
تفاوت اصلی در جهت ترافیک است: API Gateway ترافیک بین کلاینت خارجی و سرویسهای داخلی را مدیریت میکند، در حالی که Service Mesh ترافیک بین خود میکروسرویسها را مدیریت میکند. در معماریهای واقعی، معمولاً از هر دو استفاده میشود API Gateway. به عنوان در ورودی عمل میکند و درخواست های بیرونی را کنترل میکند، سپس Service Mesh در پشت صحنه ارتباط بین سرویسها را مدیریت میکند.
CQRSیک الگوی معماری است که در آن مسئولیت عملیات خواندن (Query) و نوشتن (Command) از یکدیگر جدا میشوند. در معماری سنتی، معمولاً از یک مدل یکسان برای هر دو نوع عملیات استفاده میشود. این رویکرد تا زمانی که سیستم ساده است، پاسخگو خواهد بود، اما با رشد پیچیدگیها، تداخل بین منطق خواندن و نوشتن میتواند مشکلاتی ایجاد کند.
در الگوی CQRS، دو بخش مجزا تعریف میشود. Command مربوط به عملیاتی است که وضعیت سیستم را تغییر میدهند؛ مانند ثبت سفارش، حذف یک آیتم، یا بهروزرسانی پروفایل کاربر. این عملیات معمولاً چیزی برنمیگردانند جز تأیید موفقیتآمیز بودن اجرا. در مقابل، Query مربوط به درخواستهایی است که صرفاً داده را بازیابی میکنند و هیچ تغییری در سیستم ایجاد نمیکنند.
مهمترین مزیت CQRS، امکان بهینهسازی و مقیاسپذیری مستقل هر بخش است. برای نمونه، میتوان لایه خواندن را با استفاده از دیتابیسهایی مانند Elasticsearch بهینه کرد، در حالی که لایه نوشتن همچنان از یک دیتابیس رابطهای استفاده میکند. همچنین در شرایطی که تعداد درخواستهای خواندن بسیار بیشتر از نوشتن است میتوان تنها لایه خواندن را مقیاسدهی کرد.
چالش اصلی CQRS، پدیده سازگاری نهایی (Eventual Consistency) است. به این معنا که پس از اجرای یک Command، ممکن است تغییرات بلافاصله در لایه Query منعکس نشوند و چند لحظه تأخیر وجود داشته باشد. همچنین پیچیدگی کلی سیستم افزایش مییابد، زیرا به جای یک مدل، باید دو مدل مجزا را طراحی و مدیریت کرد.
CQRS برای همه سیستمها مناسب نیست. برای پروژههای کوچک و ساده، همان رویکرد سنتی CRUD خوبه. اما هنگامی که سیستم به پیچیدگی میرسد و الگوهای خواندن و نوشتن تفاوت چشمگیری پیدا میکنند، این الگو میتواند راهگشا باشد.
معماری رویدادمحور یا EDA مدلی است که در آن سرویسها به جای اینکه مستقیم همدیگر را صدا بزنند و منتظر جواب بمانند، فقط یک Event را اعلام میکنند. هر سرویس از قبل مشخص میکند که به کدام رویدادها سرویس میدهد. وقتی آن رویداد منتشر شود، سرویس مربوطه به طور خودکار باخبر شده و کار خود را انجام میدهد. این کار باعث میشود سرویسها از هم جدا شوند و اگر یکی خراب شود، بقیه همچنان به کار خود ادامه دهند.
تفاوت اصلی با معماری سنتی این است که در روش قدیمی، سرویس A تا جواب سرویس B را نگیرد، کارش متوقف میماند. اما در EDA، سرویس A رویداد را منتشر میکند و بلافاصله کار خودش را ادامه میدهد. این یعنی سیستم سریعتر پاسخ میدهد و مقیاسپذیری بهتری دارد.
از چالشهای اصلی آن میتوان به سازگاری نهایی اشاره کرد؛ یعنی ممکن است بعد از وقوع یک رویداد، چند لحظه طول بکشد تا همه سرویسها از آن مطلع شوند. همچنین عیبیابی و ردیابی یک درخواست در این معماری دشوارتر از روش سنتی است.
Serverless Architecture یا معماری بدون سرور یک رویکرد در توسعه نرمافزارهای ابری است. با وجود نام آن، سرور همچنان وجود دارد اما توسعهدهنده دیگر مسئول مدیریت مستقیم سرورها نیست و این وظیفه بر عهده ارائهدهندگان خدمات ابری قرار میگیرد. در این معماری برنامهنویس بیشتر روی نوشتن کد و منطق برنامه تمرکز میکند و مسائل مربوط به نگهداری، مقیاسپذیری و مدیریت زیرساخت به صورت خودکار انجام میشود.
به نظر من مهمترین مزیت Serverless این است که منابع تنها در زمان نیاز مصرف میشوند. در نتیجه هزینهها کاهش پیدا میکند و سیستم میتواند متناسب با تعداد کاربران به صورت خودکار گسترش پیدا کند. یکی از مفاهیم مهم در این معماری Function as a Service است که در آن بخشهای مختلف برنامه به صورت توابع مستقل اجرا میشوند. استفاده از این معماری باعث افزایش سرعت توسعه و سادهتر شدن مدیریت سیستمهای نرمافزاری میشود.
API-first Approach یا رویکرد APIمحور یکی از روشهای طراحی نرمافزار است که در آن قبل از پیادهسازی بخشهای مختلف سیستم، APIها طراحی و مشخص میشوند. در این رویکرد ابتدا نحوه ارتباط بین بخشهای مختلف نرمافزار، نوع دادههای ورودی و خروجی و قوانین ارتباطی تعیین میشود و سپس توسعه سیستم بر اساس این طراحی انجام میگیرد. به نظر من مهمترین مزیت این روش، ایجاد هماهنگی بهتر بین تیمهای مختلف توسعه است، چون همه اعضای تیم از ابتدا یک قرارداد مشخص برای تبادل اطلاعات در اختیار دارند. و این رویکرد باعث میشود توسعهدهندگان Backend، Frontend و موبایل بتوانند به صورت همزمان روی بخشهای مختلف پروژه کار کنند. API-first به افزایش انعطافپذیری، قابلیت توسعه و نگهداری بهتر سیستم کمک میکند.
پس : در API-first اول قرارداد ارتباط بین بخشهای مختلف سیستم را طراحی میکنیم و بعد سراغ پیادهسازی میرویم.
Domain Driven Design یا DDD یک رویکرد طراحی نرمافزار است که تمرکز اصلی آن بر درک دقیق حوزه مسئله یا همان Domain است. در این روش قبل از اینکه به جزئیات فنی مانند کدنویسی یا طراحی پایگاه داده پرداخته شود، تلاش میشود مفاهیم و قوانین کسبوکار به خوبی شناخته شوند. به نظر من مهمترین ایده DDD این است که نرمافزار باید بر اساس واقعیتهای کسبوکار طراحی شود، نه صرفاً بر اساس ساختارهای فنی.
در این رویکرد، توسعهدهندگان و متخصصان کسبوکار از یک زبان مشترک برای توصیف مفاهیم سیستم استفاده میکنند تا احتمال سوءتفاهم کاهش یابد. و DDD پیشنهاد میکند سیستمهای بزرگ به بخشهای کوچکتر و مشخصی تقسیم شوند که هر کدام مسئولیت و قوانین خاص خود را داشته باشند. این موضوع باعث میشود مدیریت پیچیدگی آسانتر شود و توسعه و نگهداری سیستم در بلندمدت کیفیت بهتری داشته باشد.
منبع : مقاله Domain-Driven Design Reference، نوشته Eric Evans
Hexagonal Architecture یا معماری ششضلعی یکی از الگوهای معماری نرمافزار است که با هدف جدا کردن منطق اصلی کسبوکار (Business Logic)از بخشهای جانبی طراحی شده است. در این معماری، هسته برنامه شامل قوانین و منطق کسبوکار است و بخشهایی مانند پایگاه داده، رابط کاربری، APIها و سرویسهای خارجی از طریق رابطهای مشخصی با آن ارتباط برقرار میکنند. به هیمن دلیل تغییر در فناوریهای بیرونی تأثیر مستقیمی بر منطق اصلی برنامه نخواهد داشت. یکی از مفاهیم مهم در این معماری استفاده از Port و Adapter است. Portها نقش قراردادهای ارتباطی را دارند و Adapterها این قراردادها را برای فناوریهای مختلف پیادهسازی میکنند. این ساختار باعث میشود سیستم انعطافپذیرتر باشد و بتوان بخشهای مختلف آن را بدون ایجاد تغییرات گسترده در هسته برنامه جایگزین یا بهروزرسانی کرد
هنگام مطالعه این موضوع متوجه شدم که Hexagonal Architecture و DDD شباهت زیادی به یکدیگر دارند. در هر دو رویکرد، تمرکز اصلی روی درک و حفظ منطق کسبوکار است و فناوریهای مختلف تنها نقش ابزارهای جانبی را ایفا میکنند.
منبع : مقاله Hexagonal Architecture، نوشته Alistair Cockburn
Event Sourcing یکی از الگوهای معماری نرمافزار است که رویکرد متفاوتی نسبت به ذخیرهسازی اطلاعات دارد. در بسیاری از سیستمها تنها آخرین وضعیت دادهها ذخیره میشود، اما در Event Sourcing تمام رویدادها و تغییراتی که در طول زمان اتفاق افتادهاند ثبت و نگهداری میشوند. به جای ذخیره نتیجه نهایی، مسیر رسیدن به آن نتیجه ذخیره میشود.
این ویژگی باعث میشود تاریخچه کامل تغییرات همیشه در دسترس باشد و بررسی اتفاقات گذشته، ردیابی خطاها و تولید گزارشهای دقیق آسانتر شود.
به همین دلیل Event Sourcing در سیستمهای مالی، بانکی و سایر سامانههایی که ثبت دقیق تغییرات اهمیت زیادی دارد کاربرد گستردهای دارد. همچنین این الگو معمولاً در کنار معماریها و رویکردهایی مانند CQRS، Microservices و Event-Driven Architecture استفاده میشود، زیرا همگی بر مدیریت رویدادها و تفکیک بهتر مسئولیتهای سیستم تأکید دارند.
Low-code و No-code Platformها ابزارها و پلتفرمهایی هستند که امکان توسعه نرمافزار را با حداقل کدنویسی یا حتی بدون کدنویسی فراهم میکنند. در این پلتفرمها بسیاری از قابلیتهای مورد نیاز از طریق رابطهای گرافیکی و ابزار های آماده در اختیار کاربران قرار میگیرد و به همین دلیل فرآیند توسعه نرمافزار سریعتر انجام میشود. تفاوت اصلی این دو در این است که در No-code تقریباً نیازی به برنامهنویسی وجود ندارد، در حالی که در Low-code برای پیادهسازی بخشهای پیچیدهتر ممکن است مقدار محدودی کدنویسی لازم باشد.
از مزایای این پلتفرمها کاهش زمان و هزینه توسعه نرمافزار است و از آنها برای ساخت نمونههای اولیه، اتوماسیون فرایندهای سازمانی و توسعه سریع محصولات استفاده میشود. البته این ابزارها در کنار مزایای خود محدودیتهایی نیز دارند و معمولاً برای پروژههای بسیار بزرگ و پیچیده نمیتوانند جایگزین کامل روشهای سنتی توسعه نرمافزار شوند. با این حال، نقش آنها در افزایش سرعت توسعه و مشارکت افراد غیرمتخصص در ساخت نرمافزار قابل توجه است.
BPMS یا Business Process Management System به مجموعهای از ابزارها و نرمافزارها گفته میشود که برای طراحی، اجرا، مدیریت و بهبود فرایندهای کسبوکار در سازمانها استفاده میشوند. در بسیاری از سازمان ها فعالیت هایی مانند ثبت درخواست ها، تأیید اسناد، مدیریت مرخصی یا رسیدگی به سفارشها از چندین مرحله تشکیل شدهاند. BPMS کمک میکند این مراحل به صورت استاندارد و تا حد امکان خودکار اجرا شوند.
یکی از مهمترین مزایای BPMS افزایش شفافیت و کاهش خطاهای انسانی است، زیرا تمام مراحل یک فرایند قابل مشاهده و پیگیری هستند. همچنین این سیستمها باعث میشوند کارها با سرعت و دقت بیشتری انجام شوند و مدیران بتوانند عملکرد فرایندها را تحلیل و بهینهسازی کنند. BPMS در بسیاری از موارد با رویکردهای Low-code و No-code ترکیب میشود تا طراحی و اجرای فرایندها سادهتر و سریع تر انجام شود.
Message Queue یک الگوی ارتباطی در معماری نرمافزارهای توزیعشده است که در آن ارتباط بین سرویسها از طریق ارسال پیام و قرار گرفتن آنها در صف انجام میشود. در این روش، یک سرویس پیام را تولید کرده و در صف قرار میدهد و سرویس دیگر در زمان مناسب آن را دریافت و پردازش میکند. این مدل باعث میشود سرویسها به صورت مستقیم و همزمان به یکدیگر وابسته نباشند.
یکی از مهمترین مزایای Message Queue افزایش مقیاسپذیری و پایداری سیستم است، زیرا فشار کاری بین سرویسها توزیع میشود و سیستم در برابر بارهای سنگین مقاومتر میشود. ابزارهایی مانند RabbitMQ و Apache Kafka از معروفترین پیادهسازیهای این مفهوم هستند که در سیستمهای مختلف برای مدیریت پیامها و پردازش داده استفاده میشوند. به همین دلیل Message Queue یکی از اجزای اصلی در معماریهای مدرن مانند Microservices و Event-Driven Architecture محسوب میشود.
Container ها فناوریای هستند که امکان بستهبندی یک نرمافزار به همراه تمام وابستگیها و تنظیمات موردنیاز آن را فراهم میکنند. این ویژگی باعث میشود برنامه در محیطهای مختلف به شکل یکسان اجرا شود و مشکلات ناشی از تفاوت سیستمها کاهش یابد. Docker یکی از شناختهشدهترین ابزارهای این حوزه است و نقش مهمی در توسعه و استقرار نرمافزارهای مدرن دارد.
با افزایش تعداد کانتینرها، مدیریت آنها به یک چالش جدی تبدیل میشود. به همین دلیل ابزارهای Container Orchestration مانند Kubernetes به وجود آمدهاند. Kubernetes وظیفه مدیریت، توزیع و نظارت بر کانتینرها را بر عهده دارد و میتواند در صورت افزایش بار کاری یا بروز خطا، به صورت خودکار واکنش نشان دهد. Container ها و Kubernetes از مهمترین فناوریهای مورد استفاده در معماریهای مبتنی بر Microservices، رایانش ابری و DevOps محسوب میشوند و نقش مهمی در افزایش انعطافپذیری و مقیاسپذیری سیستمها دارند.
Multi-Tenancy Architecture یکی از الگوهای معماری نرمافزار است که در آن یک نسخه از نرمافزار به طور همزمان به چندین مشتری یا سازمان مختلف سرویس ارائه میدهد. در این معماری، کاربران از زیرساخت و منابع مشترک استفاده میکنند، اما اطلاعات و دادههای هر مشتری به صورت جداگانه نگهداری میشود. این رویکرد باعث میشود هزینههای توسعه، نگهداری و مدیریت سیستم کاهش پیدا کند و ارائهدهنده سرویس بتواند تعداد زیادی مشتری را به شکل کارآمدتری پشتیبانی کند.
یکی از مهمترین کاربردهای Multi-Tenancy در نرمافزارهای ابری و سرویسهای SaaS است. در این نوع سیستمها، همه مشتریان از یک نرمافزار مشترک استفاده میکنند، اما هر کدام فقط به دادههای خود دسترسی دارند. استفاده از این معماری باعث بهرهوری بیشتر منابع و سادهتر شدن فرآیند بهروزرسانی نرمافزار میشود.
Data Migration یا مهاجرت دادهها به فرآیند انتقال اطلاعات از یک سیستم یا پایگاه داده به سیستم جدید گفته میشود. این کار معمولاً زمانی انجام میشود که یک سازمان قصد داشته باشد نرمافزار، پایگاه داده یا زیرساخت فناوری خود را بهروزرسانی کند. در چنین شرایطی، علاوه بر راهاندازی سیستم جدید، لازم است دادههای قبلی نیز به درستی منتقل شوند تا فعالیتهای سازمان بدون مشکل ادامه پیدا کند.
فرآیند مهاجرت داده تنها شامل جابهجایی اطلاعات نیست، بلکه معمولاً مراحل بررسی، پاکسازی، تبدیل و اعتبارسنجی دادهها را نیز در بر میگیرد. اهمیت این موضوع از آنجا مشخص میشود که کوچکترین خطا در انتقال اطلاعات میتواند باعث از دست رفتن دادههای ارزشمند یا ایجاد مشکلات عملیاتی شود. به همین دلیل Data Migration یکی از مراحل حساس در پروژههای نرمافزاری و تحول دیجیتال محسوب میشود و نیاز به برنامهریزی و آزمایش دقیق دارد.
