مطالبی دربارهی معماری نرم افزار

در اینجا به بعضی مطالب مهم در معماری نرم افزار می پردازیم

مهندسی آشوب (Chaos Engineering)

چگونه از سلامت بدن در برابر بیماری‌های ناشناخته مطمئن می‌شویم؟ با واکسیناسیون؛ یعنی تزریق کنترل‌شده‌ی یک عامل ضعیف‌شده تا سیستم ایمنی بدن برای مقابله با تهدید واقعی، قوی‌تر و آماده‌تر شود. مهندسی آشوب (Chaos Engineering) دقیقاً همین نقش را برای سیستم‌های نرم‌افزاری پیچیده ایفا می‌کند. این رویکرد، به جای امید داشتن به اینکه هرگز مشکلی پیش نیاید، فعالانه و به صورت یک آزمایش علمی به دنبال کشف نقاط ضعف سیستم می‌رود.

در مهندسی آشوب، ما به صورت عمدی و البته کاملاً کنترل‌شده، شرایط بحرانی و خرابی‌های احتمالی را در یک محیط واقعی یا بسیار نزدیک به واقعیت شبیه‌سازی می‌کنیم. برای مثال، از خود می‌پرسیم: “چه اتفاقی می‌افتد اگر یکی از سرورهای اصلی پایگاه داده ما به طور ناگهانی از دسترس خارج شود؟” یا “اگر ترافیک کاربران در یک لحظه ده برابر حد معمول شود، آیا کل سیستم از کار می‌افتد یا می‌تواند به شکلی هوشمندانه با شرایط کنار آمده و به ارائه خدمات حداقلی ادامه دهد؟”

هدف نهایی مهندسی آشوب، ایجاد خرابی بی‌دلیل نیست؛ بلکه افزایش اعتماد به نفس ما نسبت به پایداری و مقاومت سیستم است. با این آزمایش‌های کنترل‌شده، ما پیش از آنکه کاربران واقعی با مشکل مواجه شوند، محدودیت‌ها و نقاط شکست پنهان سیستم را شناسایی کرده و برای رفع آن‌ها اقدام می‌کنیم. در نهایت، این تمرین به ما کمک می‌کند تا سیستم‌هایی بسازیم که نه تنها در شرایط ایده‌آل، بلکه در مواجهه با آشوب‌های دنیای واقعی نیز قابل اتکا و پایدار باقی بمانند.

مراجع:

• https://principlesofchaos.org/

• https://parsdev.com/blog/chaos-engineering/

سیستم‌های مدیریت فرآیندهای کسب‌وکار (BPMS)

یک سازمان را مانند یک ارکستر بزرگ تصور کنید. برای اجرای یک قطعه موسیقی بی‌نقص، هر نوازنده باید نت خود را در زمان دقیق و به شیوه‌ی صحیح بنوازد. اگر یک رهبر ارکستر برای هماهنگی این نوازندگان وجود نداشته باشد، نتیجه چیزی جز یک صدای ناهماهنگ و آشفته نخواهد بود. سیستم مدیریت فرآیندهای کسب‌وکار (BPMS) دقیقاً نقش آن رهبر ارکستر را برای فرآیندهای یک سازمان ایفا می‌کند. این سیستم، ابزاری نرم‌افزاری است که به جای یادداشت‌های شفاهی یا زنجیره‌های بی‌پایان ایمیل، یک «پارتیتور» دیجیتال و هوشمند برای فرآیندهای کاری تعریف می‌کند.

در عمل، یک BPMS به ما اجازه می‌دهد تا تمام مراحل یک فرآیند کاری، مانند «فرآیند استخدام یک نیروی جدید» یا «فرآیند رسیدگی به درخواست مرخصی»، را به صورت یک نمودار بصری مدل‌سازی کنیم. پس از طراحی، موتور BPMS این نقشه را به یک گردش کار اجرایی تبدیل می‌کند؛ به طور خودکار وظایف را به افراد یا دپارتمان‌های مربوطه ارجاع می‌دهد، مهلت‌ها را یادآوری می‌کند، اسناد را در مسیر درست به جریان می‌اندازد و تضمین می‌کند که هیچ مرحله‌ای از قلم نیفتد.

مزیت اصلی این رویکرد، تبدیل آشفتگی‌های سازمانی به فرآیندهایی شفاف، قابل ردیابی و بهینه است. با BPMS، مدیران می‌توانند به سادگی گلوگاه‌ها را شناسایی کرده و عملکرد کلی را تحلیل کنند. این سیستم‌ها خطاهای انسانی را کاهش می‌دهند، سرعت انجام کارها را به شدت افزایش می‌دهند و به سازمان کمک می‌کنند تا خود را با تغییرات و قوانین جدید به سرعت تطبیق دهد. به طور خلاصه، BPMS فرآیندهای کسب‌وکار را از یک مسئولیت پنهان و پراکنده، به یک دارایی ارزشمند، مدیریت‌شده و هوشمند تبدیل می‌کند.

مراجع:

• Teamyar: https://www.teamyar.com/نرم-افزار-BPMS

• Microsoft: https://www.microsoft.com/en-us/power-platform/products/power-automate/topics/business-process/bpms-business-process-management-software

صف پیام (Message Queue)؛ مانند Kafka و RabbitMQ

تصور کنید می‌خواهید بسته‌ای را به دوستتان تحویل دهید. یک راه این است که مستقیماً به در خانه‌اش بروید و منتظر بمانید تا در را باز کند. این یک ارتباط «همزمان» (Synchronous) است؛ شما تا زمانی که پاسخ نگیرید، معطل می‌شوید. اما راه بهتر چیست؟ بسته را به اداره پست تحویل می‌دهید و به کارهای خود می‌رسید. اداره پست تضمین می‌کند که بسته در زمان مناسب به دست دوستتان خواهد رسید، حتی اگر او در آن لحظه در خانه نباشد. این ارتباط «غیرهمزمان» (Asynchronous) است و اداره پست در اینجا نقش یک صف پیام (Message Queue) را بازی می‌کند.

در دنیای معماری نرم‌افزار، صف‌های پیام دقیقاً همین کار را برای سرویس‌های مختلف انجام می‌دهند. به جای اینکه سرویس A مستقیماً با سرویس B تماس بگیرد و منتظر پاسخ بماند، پیام خود (مثلاً «یک سفارش جدید ثبت شد») را در یک صف قرار می‌دهد. سرویس B هر زمان که آماده بود، این پیام را از صف برداشته و پردازش می‌کند.

این جداسازی، مزایای فوق‌العاده‌ای دارد:

1. پایداری (Resilience): اگر سرویس گیرنده موقتاً از کار بیفتد، پیام از بین نمی‌رود و در صف منتظر می‌ماند تا سرویس دوباره آنلاین شود.

2. مقیاس‌پذیری (Scalability): اگر تعداد پیام‌ها ناگهان زیاد شود، به سادگی در صف قرار می‌گیرند و می‌توانیم تعداد سرویس‌های پردازش‌کننده (مصرف‌کننده‌ها) را افزایش دهیم تا صف را سریع‌تر خالی کنند.

3. کاهش وابستگی (Decoupling): سرویس فرستنده و گیرنده نیازی به شناخت یکدیگر ندارند و کاملاً مستقل از هم کار می‌کنند.

ابزارهایی مانند RabbitMQ بیشتر شبیه یک اداره پست هوشمند عمل می‌کنند که پیام‌ها را با قوانین پیچیده به مقصدهای مختلف می‌رسانند. در مقابل، Apache Kafka بیشتر شبیه یک سیستم پخش زنده یا یک دفتر ثبت وقایع عمل می‌کند که جریانی پایان‌ناپذیر از رویدادها را ضبط کرده و به چندین سرویس اجازه می‌دهد به این جریان گوش دهند و آن را تحلیل کنند.

مراجع:

• https://danapedia.ir/message-queue-چیست-rabbitmq/

• https://pouyanit.com/blog/rabbitmq-بررسی-مزایا-و-نحوه-عملکرد/

• https://7learn.com/blog/what-is-kafka

• https://ably.com/topic/apache-kafka-vs-rabbitmq-vs-aws-sns-sqs

• https://aws.amazon.com/compare/the-difference-between-rabbitmq-and-kafka/

کانتینرها (مانند Docker) و ارکستراسیون کانتینر (مانند Kubernetes)

یکی از قدیمی‌ترین مشکلات دنیای نرم‌افزار، جمله معروف «اما روی کامپیوتر من کار می‌کرد!» است. برنامه‌ای که در محیط توسعه به خوبی اجرا می‌شود، ممکن است به دلیل تفاوت در سیستم‌عامل، کتابخانه‌ها یا تنظیمات، در سرور اصلی دچار مشکل شود. کانتینرها (Containers) برای حل این مشکل به وجود آمدند. یک کانتینر را مانند یک جعبه استاندارد و ایزوله در نظر بگیرید که نه تنها خود برنامه، بلکه تمام نیازمندی‌هایش (کتابخانه‌ها، کدها و تنظیمات) را در خود جای داده است. Docker محبوب‌ترین ابزار برای ساختن و اجرای این “جعبه‌ها” است. با استفاده از داکر، ما اطمینان حاصل می‌کنیم که برنامه ما در هر محیطی که از داکر پشتیبانی کند، به شکلی یکسان و قابل پیش‌بینی اجرا خواهد شد.

حالا مشکل جدیدی پیش می‌آید. مدیریت یک یا چند کانتینر ساده است، اما یک سیستم بزرگ مانند دیجی‌کالا یا اسنپ ممکن است از هزاران کانتینر مختلف تشکیل شده باشد. چگونه این ارتش عظیم از کانتینرها را مدیریت کنیم؟ چه اتفاقی می‌افتد اگر یکی از آن‌ها از کار بیفتد؟ چگونه ترافیک را بین آن‌ها تقسیم کنیم؟ اینجا است که ارکستراسیون کانتینر (Container Orchestration) وارد میدان می‌شود.

Kubernetes (کوبرنتیز) مانند یک رهبر ارکستر برای این کانتینرها عمل می‌کند. این سیستم به طور خودکار وظایف پیچیده مدیریت را بر عهده می‌گیرد:

• سلامت سیستم: اگر یک کانتینر دچار مشکل شود، کوبرنتیز به طور خودکار آن را از بین برده و یک نسخه سالم جایگزین می‌کند.

• مقیاس‌پذیری: در زمان اوج ترافیک، به صورت هوشمند تعداد کانتینرهای در حال اجرا را افزایش می‌دهد و پس از آن، آن‌ها را کم می‌کند.

• توزیع بار: ترافیک ورودی را به صورت بهینه بین کانتینرهای سالم تقسیم می‌کند.

به طور خلاصه، داکر ابزاری برای ساختن و بسته‌بندی یک واحد نرم‌افزاری قابل حمل است، در حالی که کوبرنتیز یک مغز متفکر برای مدیریت و هماهنگی هزاران عدد از این واحدها در مقیاس صنعتی است.

مراجع:

• https://aws.amazon.com/compare/the-difference-between-kubernetes-and-docker/

• https://mgtechsoft.com/blog/containerization-and-orchestration-docker-vs-kubernetes/

• https://liara.ir/blog/چکپوینت-کانتینر-در-docker-و-kubernetes/

معماری چندمستأجری (Multi-Tenancy Architecture)

ساختن یک خانه ویلایی مجزا برای هر خانواده را تصور کنید. این کار بسیار گران، زمان‌بر و نیازمند مدیریت جداگانه برای هر خانه است. حالا یک مجتمع آپارتمانی مدرن را در نظر بگیرید: یک ساختمان واحد با زیرساخت‌های مشترک (مانند موتورخانه، آسانسور و لوله‌کشی) که چندین خانواده در واحدهای کاملاً مجزا و امن خود زندگی می‌کنند. معماری چندمستأجری در دنیای نرم‌افزار، دقیقاً همان ایده هوشمندانه مجتمع آپارتمانی است.

در این معماری، یک نسخه واحد از نرم‌افزار بر روی یک زیرساخت مشترک نصب شده و به چندین مشتری یا «مستأجر» (Tenant) به صورت همزمان سرویس می‌دهد. هر مستأجر (که معمولاً یک سازمان یا یک تیم است) فضای کاری، داده‌ها و تنظیمات مخصوص به خود را دارد که از دیگران کاملاً ایزوله شده است. به عبارت دیگر، هیچ مستأجری کلید آپارتمان دیگری را ندارد و حتی ممکن است از وجود همسایه‌های خود بی‌خبر باشد.

این رویکرد ستون فقرات اکثر سرویس‌های ابری مدرن مانند Slack، Trello یا Google Workspace است. مزایای اصلی آن عبارتند از:

• کاهش چشمگیر هزینه‌ها: به جای راه‌اندازی و نگهداری سرورها و پایگاه‌های داده مجزا برای هر مشتری، از منابع مشترک استفاده می‌شود.

• نگهداری و به‌روزرسانی متمرکز: با یک‌بار به‌روزرسانی هسته نرم‌افزار، تمام مشتریان به طور همزمان از قابلیت‌های جدید و اصلاحات امنیتی بهره‌مند می‌شوند.

چالش اصلی در این معماری، تضمین امنیت و ایزوله‌سازی کامل داده‌های هر مستأجر است تا هیچ‌گونه نشت اطلاعاتی بین آن‌ها رخ ندهد. در نهایت، Multi-Tenancy مدلی اقتصادی و بهینه برای ارائه خدمات نرم‌افزاری در مقیاس بزرگ است.

مراجع:

• https://www.geeksforgeeks.org/system-design/multi-tenancy-architecture-system-design/

• https://dev.to/tak089/multi-tenant-architecture-a-complete-guide-basic-to-advanced-119o

• https://mihanwebhost.com/blog/articles/1740/م�%8ﻌماری-multi-tenant-مزایا-چالشها-و-انواع-آن

• https://liara.ir/blog/multi-tenancy-یا-چند-مستاجری-چیست/

مهاجرت داده (Data Migration)

جابجایی داده (Data Migration) را می‌توان به یک عمل جراحی حساس مانند «پیوند عضو» برای یک سیستم نرم‌افزاری تشبیه کرد. در این فرآیند، ما قلب تپنده سیستم، یعنی داده‌های آن را، از یک بدن قدیمی (سیستم منبع) به یک بدن جدید و پیشرفته‌تر (سیستم مقصد) منتقل می‌کنیم. این کار بسیار فراتر از یک کپی-پیست ساده است، همانطور که پیوند عضو، چیزی فراتر از جابجا کردن یک ارگان است.

دلایل این جابجایی متنوع است: ارتقا به یک پایگاه داده جدیدتر، انتقال زیرساخت به فضای ابری (Cloud)، یا ادغام داده‌های دو شرکت پس از یک قرارداد بزرگ. در هر یک از این سناریوها، ساختار، زبان و قوانین سیستم جدید ممکن است با سیستم قدیم تفاوت داشته باشد. بنابراین، داده‌ها باید در حین انتقال، استخراج (Extract)، پاک‌سازی و به فرمت جدید تبدیل (Transform) و سپس با دقت در جایگاه صحیح خود در سیستم مقصد بارگذاری (Load) شوند.

مهم‌ترین چالش در مهاجرت داده، حفظ یکپارچگی و سلامت آن است. هرگونه خطا در این فرآیند می‌تواند به از دست رفتن داده‌های حیاتی (Data Loss) یا تخریب آن‌ها (Data Corruption) منجر شود که عواقب فاجعه‌باری برای یک کسب‌وکار دارد. به همین دلیل، مهاجرت داده یک عملیات مهندسی دقیق و برنامه‌ریزی‌شده است که نیازمند استراتژی‌های مشخص برای پشتیبان‌گیری، اعتبارسنجی و به حداقل رساندن زمان قطعی سرویس (Downtime) می‌باشد.

مراجع:

• https://amirsalehi.ir/blog/what-is-migration-and-why-do-we-use-it/

• https://persianapi.com/پردازش-داده-ها/مهاجرت-داده-data-migration-چیست؟/

بک‌اند برای فرانت‌اند (Backend for Frontend - BFF)

الگوی BFF به این معناست که به‌جای استفاده از یک بک‌اند مشترک برای همه‌ی کلاینت‌ها، برای هر نوع کلاینت یک بک‌اند جداگانه در نظر گرفته شود. در این روش، هر رابط کاربری مانند وب‌سایت، اپلیکیشن موبایل یا سایر کلاینت‌ها، بک‌اند مخصوص خود را دارد و فقط داده‌ها و قابلیت‌هایی را دریافت می‌کند که واقعاً به آن نیاز دارد.

در بسیاری از سیستم‌ها، کلاینت‌ها نیازهای یکسانی ندارند. برای مثال، یک اپلیکیشن موبایل معمولاً به داده‌های کمتر و سبک‌تری نسبت به نسخه وب نیاز دارد. اگر همه‌ی کلاینت‌ها از یک بک‌اند عمومی استفاده کنند، ممکن است اطلاعات اضافی دریافت کنند، پیچیدگی بک‌اند بیشتر شود و عملکرد سیستم کاهش پیدا کند.

الگوی BFF این مشکل را برطرف می‌کند. این الگو باعث می‌شود هر کلاینت فقط داده‌های مورد نیاز خودش را دریافت کند، ارتباط بین فرانت‌اند و بک‌اند ساده‌تر شود و کارایی برنامه بهتر شود. به همین دلیل، BFF در سیستم‌هایی که چند نوع رابط کاربری دارند، یک راهکار مفید و کاربردی محسوب می‌شود.

منابع

• GeeksforGeeks - Backend for Frontend Pattern

• Hostragons - BFF Backend for Frontend

هوش مصنوعی برای مهندسی نرم‌افزار (AI4SE)

هوش مصنوعی برای مهندسی نرم‌افزار یا AI4SE به استفاده از هوش مصنوعی برای پشتیبانی، بهبود یا خودکارسازی فعالیت‌های مختلف در چرخه‌ی توسعه نرم‌افزار گفته می‌شود. این فعالیت‌ها می‌توانند از مرحله‌ی تحلیل و طراحی شروع شوند و تا تست، نگهداری و خطایابی ادامه پیدا کنند.

استفاده از هوش مصنوعی می‌تواند فرآیند توسعه نرم‌افزار را سریع‌تر، دقیق‌تر و کارآمدتر کند. برای مثال، این فناوری به مهندسان کمک می‌کند تا مدل‌های پیچیده‌تری بسازند، داده‌های بزرگ را بهتر پردازش کنند و هزینه و زمان توسعه را کاهش دهند. در نتیجه، محصول نهایی معمولاً کیفیت بالاتری دارد، خطاهای کمتری در آن دیده می‌شود و عملکرد بهتری ارائه می‌دهد.

با این حال، باید توجه داشت که هوش مصنوعی فقط یک ابزار کمکی است و جایگزین کامل مهندسان نرم‌افزار نمی‌شود. تصمیم‌گیری، خلاقیت و درک نیازهای واقعی سیستم همچنان به تخصص انسان نیاز دارد.

منابع

• Detec - ترکیب هوش مصنوعی با نرم‌افزارهای مهندسی

مهندسی نرم‌افزار برای سیستم‌های هوش مصنوعی (SE4AI)

SE4AI به این موضوع می‌پردازد که چگونه می‌توان از اصول و فرایندهای مهندسی نرم‌افزار برای ساخت و مدیریت سیستم‌های مبتنی بر هوش مصنوعی استفاده کرد.

با گسترش کاربرد هوش مصنوعی در حوزه‌هایی مثل سلامت، صنعت خودرو و خدمات عمومی، نیاز به رویکردهای مهندسی‌شده برای توسعه این سیستم‌ها بیشتر شده است. در چنین سیستم‌هایی، استفاده از روش‌های معمول برنامه‌نویسی کافی نیست؛ چون سیستم‌های مبتنی بر AI با چالش‌هایی مثل داده‌های پویا، رفتار غیرقطعی مدل‌ها، نیاز به به‌روزرسانی مداوم و مسائل مربوط به استقرار و نگهداری روبه‌رو هستند.

به همین دلیل، مهندسان نرم‌افزار به این نتیجه رسیده‌اند که می‌توان بسیاری از اصول رایج در توسعه نرم‌افزار، مانند طراحی معماری، تضمین کیفیت، تست، استقرار و نگهداری را برای ساخت سیستم‌های هوش مصنوعی نیز به‌کار گرفت. در واقع، SE4AI تلاش می‌کند این شکاف را پر کند و نشان دهد که چگونه می‌توان سیستم‌های AI را به‌صورت پایدار، قابل‌اعتماد و قابل‌نگهداری توسعه داد.

منبع

• SE4AI - TU Delft

• Software Engineering for AI-Enabled Systems Course

MLOps

MLOps مجموعه‌ای از روش‌ها و فعالیت‌ها برای توسعه، استقرار و نگهداری مدل‌های یادگیری ماشین است. در این رویکرد، فقط کد نرم‌افزار مدیریت نمی‌شود، بلکه داده‌ها، ویژگی‌ها و خود مدل نیز بخشی از فرایند هستند. به همین دلیل، MLOps کمک می‌کند تا کار با مدل‌های یادگیری ماشین به‌صورت منظم‌تر، قابل‌اعتمادتر و قابل‌تکرار انجام شود.

در MLOps بخش‌های مختلف چرخه‌ی عمر مدل، از آماده‌سازی داده‌ها و آموزش مدل گرفته تا ارزیابی، استقرار، نظارت و به‌روزرسانی آن مدیریت می‌شوند. همچنین اگر عملکرد مدل در طول زمان کاهش پیدا کند، فرایند آموزش مجدد و نسخه‌بندی آن نیز در همین چارچوب انجام می‌شود. این کار باعث می‌شود کیفیت، پایداری و نگهداری سیستم‌های مبتنی بر یادگیری ماشین بهتر شود.

منابع

• دراک - MLOps چیست؟

• لیارا - MLOps چیست؟

Infrastructure as Code (IaC)

زیرساخت به عنوان کد یا Infrastructure as Code (IaC) یعنی به جای انجام کارها به صورت دستی، زیرساخت را با استفاده از کد ایجاد و مدیریت کنیم. در این روش، منابعی مثل سرورها، شبکه‌ها، پایگاه‌داده‌ها و سرویس‌های ابری از طریق فایل‌ها و اسکریپت‌ها تعریف می‌شوند. این کار باعث می‌شود فرایند راه‌اندازی و مدیریت زیرساخت سریع‌تر انجام شود، پیچیدگی کاهش پیدا کند، خطای انسانی کمتر شود و در نهایت کار با کیفیت‌تر و قابل‌اعتمادتر باشد.

پیاده‌سازی IaC به دو صورت اعلامی و دستوری انجام می‌شود. در روش اعلامی (Declarative) فقط وضعیت نهایی موردنظر مشخص می‌شود و ابزار خودش مراحل رسیدن به آن را انجام می‌دهد. اما در روش دستوری (Imperative) تمام مراحل از ابتدا تا انتها به‌صورت دقیق نوشته می‌شوند و ابزار باید همان مراحل را اجرا کند. به طور کلی، IaC یکی از پایه‌های مهم در DevOps است و به استانداردسازی، تکرارپذیری و مدیریت بهتر زیرساخت کمک می‌کند.

منابع

• Red Hat - What is Infrastructure as Code (IaC)

• لیارا - زیرساخت به عنوان کد (IaC) چیست؟

• همراه اول/همرا‌ه‌وب؟ - Infrastructure as Code

Serverless Architecture

معماری بدون سرور یا Serverless Architecture یک سبک معماری در رایانش ابری است که در آن مدیریت سرورها، سیستم‌عامل و زیرساخت بر عهده‌ی ارائه‌دهنده‌ی سرویس ابری است. در این معماری، توسعه‌دهندگان دیگر درگیر راه‌اندازی و نگهداری سرور نمی‌شوند و تمام تمرکز خود را روی منطق برنامه و توسعه‌ی قابلیت‌های نرم‌افزار می‌گذارند.

این معماری معمولاً باعث کاهش هزینه‌ها و افزایش بهره‌وری می‌شود، چون منابع فقط زمانی مصرف می‌شوند که برنامه در حال اجرا باشد. با این حال، Serverless محدودیت‌هایی هم دارد؛ برای مثال ممکن است منابع اجرایی محدود باشند، یا در بعضی شرایط با تأخیرهایی مثل Cold Start روبه‌رو شویم. به همین دلیل، این معماری برای همه‌ی سناریوها مناسب نیست، اما برای بسیاری از برنامه‌های مقیاس‌پذیر و رویدادمحور انتخاب بسیار خوبی است.

منابع

• Mobinhost - What is Serverless Architecture?

• همراه‌وب - What is Serverless?

• GeeksforGeeks - Serverless Architectures

API Gateway & Service Mesh

API Gateway یک مولفه در معماری سیستم است که مانند یک دروازه برای ورود درخواست‌های کلاینت عمل می‌کند. این لایه درخواست‌ها را دریافت می‌کند، آن‌ها را از نظر احراز هویت و اعتبارسنجی بررسی می‌کند و سپس درخواست را به سرویس مناسب هدایت می‌کند. در نتیجه، کلاینت به‌جای ارتباط مستقیم با چند سرویس مختلف، فقط از یک نقطه ورود با سیستم ارتباط می‌گیرد.

Service Mesh نیز لایه‌ای از زیرساخت در معماری میکروسرویس است که ارتباطات بین سرویس‌ها را مدیریت می‌کند. برخلاف API Gateway که بیشتر روی ارتباط کلاینت با سرویس‌ها تمرکز دارد، Service Mesh مسئول ارتباط سرویس با سرویس است و به بهبود امنیت، قابلیت مشاهده، کنترل ترافیک و پایداری ارتباطات داخلی کمک می‌کند.

به‌طور خلاصه، API Gateway برای مدیریت درخواست‌های ورودی از بیرون سیستم استفاده می‌شود، اما Service Mesh برای مدیریت ارتباطات داخلی میان میکروسرویس‌ها به‌کار می‌رود.

منابع

• Solo.io - Service Mesh vs API Gateway

• Akamai - API Gateway vs Service Mesh

• چابکان - API Gateway چیست و چرا در معماری میکروسرویس لازم است؟

CQRS (Command Query Responsibility Segregation)

CQRS یک الگوی معماری است که مسئولیت نوشتن را از مسئولیت خواندن جدا می‌کند. در این الگو، عملیاتی که باعث تغییر وضعیت سیستم می‌شوند، در بخش Command قرار می‌گیرند و عملیاتی که فقط داده را دریافت و نمایش می‌دهند، در بخش Query. به همین دلیل، هر کدام از این دو بخش می‌توانند به‌صورت مستقل طراحی و بهینه‌سازی شوند.

این جداسازی باعث می‌شود مدل خواندن سریع‌تر و سبک‌تر باشد، و در عین حال عملیات نوشتن روی خواندن تأثیر منفی نگذارد. همچنین چون هر بخش نیازهای متفاوتی دارد، پیچیدگی سیستم کمتر می‌شود و می‌توان برای هر قسمت ساختار مناسب‌تری در نظر گرفت. در سیستم‌هایی که تعداد درخواست‌های خواندن بیشتر از نوشتن است یا منطق کسب‌وکار پیچیده‌ای دارند، CQRS می‌تواند انتخاب بسیار مفیدی باشد.

منابع

• آساکس - CQRS چیست؟

• GeeksforGeeks - CQRS

• Microsoft Azure Architecture - CQRS pattern

• Medium - CQRS: A Deep Dive into Command Query Responsibility Segregation

• بوگتو - CQRS در میکروسرویس

EDA (Event-Driven Architecture)

EDA یا معماری رویدادمحور الگویی در طراحی نرم‌افزار است که در آن اجزای سیستم از طریق رویدادها با یکدیگر ارتباط برقرار می‌کنند. در این معماری، به‌جای فراخوانی مستقیم سرویس‌ها، هر جزء با تغییر وضعیت سیستم یا وقوع یک اتفاق مهم، رویداد تولید می‌کند و سایر اجزا بر اساس آن رویداد واکنش نشان می‌دهند. به همین دلیل، فرستنده و گیرنده لازم نیست منتظر پاسخ مستقیم یکدیگر بمانند و ارتباط معمولاً به‌صورت غیرهمزمان انجام می‌شود.

یکی از مزیت‌های اصلی EDA، اتصال سست بین اجزای سیستم است؛ یعنی سرویس‌ها وابستگی مستقیم و شدیدی به هم ندارند و می‌توانند مستقل‌تر توسعه، استقرار و مقیاس‌دهی شوند. این الگو برای سیستم‌هایی که نیاز به واکنش سریع، مقیاس‌پذیری و پردازش در لحظه دارند بسیار مناسب است.

اجزای اصلی

• Event Source / Producer: تولیدکننده رویداد

• Event: خودِ رویداد یا تغییر وضعیت

• Event Broker / Event Bus: واسطه یا گذرگاه رویداد

• Subscriber / Consumer: مصرف‌کننده یا مشترک رویداد

منابع

• GeeksforGeeks - Event-Driven Architecture

• همراه‌وب - Event Driven Architecture چیست؟

• آساکس - Event Driven Architecture

• پرشین ای‌پی‌آی - معماری رویدادمحور (EDA) چیست؟

API-First Approach

API-First Approach یک متدولوژی در طراحی و توسعه نرم‌افزار است که در آن API به‌عنوان قرارداد اصلی سیستم در مرکز طراحی قرار می‌گیرد. در این رویکرد، ابتدا نیازها و نوع کلاینت‌ها مشخص می‌شوند و سپس API متناسب با آن‌ها طراحی می‌شود. بعد از تثبیت API، پیاده‌سازی بک‌اند و فرانت‌اند بر اساس همان قرارداد انجام می‌شود.

این روش باعث می‌شود تیم‌های مختلف بتوانند هم‌زمان و با وابستگی کمتر روی بخش‌های مختلف سیستم کار کنند. همچنین چون API از ابتدا دقیق تعریف می‌شود، یکپارچگی، قابلیت استفاده‌مجدد، مقیاس‌پذیری و سرعت توسعه بهتر می‌شود. API-First به‌ویژه برای سیستم‌هایی که چندین کلاینت مثل وب، موبایل، شرکای تجاری یا سرویس‌های داخلی دارند، بسیار کاربردی است.

منابع

• Hostragons - رویکرد API-First در توسعه وب

• Postman - API-First

Domain-Driven Design (DDD)

Domain-Driven Design یک رویکرد توسعه نرم‌افزار است که تمرکز اصلی آن روی دامنه مسئله و منطق کسب‌وکار است. در DDD، ساختار نرم‌افزار بر اساس قوانین دامنه، مفاهیم کسب‌وکار و روابط واقعی مسئله طراحی می‌شود، نه صرفاً بر اساس لایه‌های فنی یا دیتامدل‌های خام.

هدف اصلی DDD این است که مدل نرم‌افزار با مدل ذهنی کسب‌وکار هم‌راستا شود تا تیم فنی و متخصصان دامنه بتوانند با یک زبان مشترک کار کنند و پیچیدگی‌های کسب‌وکار را بهتر مدیریت کنند. این رویکرد به‌ویژه برای سیستم‌های پیچیده و دامنه‌های پر از قانون و استثنا بسیار مناسب است.

مفاهیم کلیدی

• Ubiquitous Language: زبان مشترک بین توسعه‌دهندگان و خبرگان کسب‌وکار

• Bounded Context: تعیین مرز روشن برای هر مدل دامنه

• Entities: اشیایی با هویت یکتا و تغییرپذیر

• Value Objects: اشیای بدون هویت، تعریف‌شده با مقدار و معمولاً غیرقابل‌تغییر

• Aggregates: گروهی از اشیای دامنه که به‌عنوان یک واحد سازگاری مدیریت می‌شوند

مزایا

• هم‌راستایی بهتر نرم‌افزار با نیازهای واقعی کسب‌وکار

• کاهش ابهام بین تیم فنی و دامنه

• مدیریت بهتر پیچیدگی در سیستم‌های بزرگ

• افزایش قابلیت نگهداری و توسعه‌پذیری

منابع

• Martin Fowler — Domain-Driven Design

• dev.to — Domain Driven Design

• 7Learn — DDD چیست؟

Hexagonal Architecture

Hexagonal Architecture یا Ports and Adapters یک الگوی معماری نرم‌افزار است که در آن هسته‌ی سیستم شامل منطق کسب‌وکار در مرکز قرار می‌گیرد و ارتباط با دنیای بیرون از طریق Ports و Adapters انجام می‌شود.

در این معماری:

• Ports نقش قرارداد یا اینترفیس ارتباطی را دارند.

• Adapters پیاده‌سازی آن قراردادها هستند و سیستم را به دنیای بیرون مثل UI، دیتابیس، API، پیام‌سازها و سرویس‌های خارجی وصل می‌کنند.

• هدف این است که منطق دامنه از جزئیات زیرساخت مستقل بماند.

نتیجه‌ی این جداسازی

• وابستگی سیستم به دیتابیس یا فریم‌ورک کاهش پیدا می‌کند

• تست‌پذیری بهتر می‌شود

• تعویض فناوری‌ها ساده‌تر می‌شود

• نگهداری و توسعه‌ی سیستم راحت‌تر می‌شود

نکته مهم

Hexagonal Architecture از نظر مفهومی با DDD هم‌راستا است، چون هر دو بر مرکزیت دامنه و کاهش وابستگی به جزئیات فنی تأکید دارند.

منابع

• GeeksforGeeks — Hexagonal Architecture

• 7Learn — معماری Hexagonal چیست؟

• Cybermedian — Hexagonal Architecture Diagram

Event Sourcing

الگوی معماری Event Sourcing رویکردی نوین در مدیریت داده‌هاست که به‌جای ذخیره‌سازی آخرین وضعیت (Current State) یک موجودیت، تمام تغییرات و اتفاقات مربوط به آن را به‌صورت مجموعه‌ای از رویدادهای تغییرناپذیر و به ترتیب زمانی در یک بانک اطلاعاتی مخصوص به نام Event Store ثبت می‌کند. در این روش، هر رویداد نشان‌دهنده‌ی یک واقعه‌ی قطعی در گذشته است که وضعیت سیستم را تغییر داده و از آنجایی که این رویدادها فقط به انتهای لیست اضافه می‌شوند (Append-only)، تاریخچه‌ای کامل و غیرقابل‌انکار از تمام فعالیت‌های سیستم به‌وجود می‌آید. برای به‌دست آوردن وضعیت فعلی یک موجودیت، سیستم تمام رویدادهای مربوط به آن را از ابتدا بازخوانی و پردازش (Replay) می‌کند تا به نتیجه نهایی برسد.

این معماری مزایای فنی و عملیاتی گسترده‌ای دارد که از جمله‌ی آن‌ها می‌توان به ایجاد یک Audit Log دقیق و خودکار برای ردیابی خطاها یا بازرسی‌های قانونی، قابلیت «سفر در زمان» برای بازگرداندن سیستم به یک نقطه خاص از گذشته و رفع پیچیدگی‌های مربوط به تداخل داده‌ها در سیستم‌های توزیع‌شده اشاره کرد. همچنین این الگو به‌خوبی با معماری CQRS ترکیب می‌شود، چرا که مدل نوشتن (رویدادها) را کاملاً از مدل خواندن (نمای وضعیت) جدا می‌کند. با وجود پیچیدگی‌های پیاده‌سازی، Event Sourcing برای سیستم‌های مالی، زنجیره تأمین و هر پلتفرمی که صحت و تاریخچه داده‌ها در آن حیاتی است، یک انتخاب استراتژیک محسوب می‌شود.

منابع:

• Microsoft Azure: https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

• GeeksforGeeks: https://www.geeksforgeeks.org/system-design/event-sourcing-pattern/

Low-code / No-code (LCNC)

پلتفرم‌های Low-code / No-code (LCNC) ابزارهایی برای ساخت نرم‌افزار هستند که به‌جای کدنویسی سنتی، از رابط‌های بصری، Drag & Drop، قالب‌های آماده و پیکربندی استفاده می‌کنند. در No-code هدف این است که حتی کاربران غیرتوسعه‌دهنده هم بتوانند بدون نوشتن کد، اپلیکیشن یا فرایند بسازند؛ اما در Low-code بخش عمده کار با ابزارهای بصری انجام می‌شود و در صورت نیاز، امکان نوشتن کد برای منطق‌های خاص، سفارشی‌سازی یا یکپارچه‌سازی‌های پیچیده هم وجود دارد. به همین دلیل، Low-code معمولاً انعطاف بیشتری نسبت به No-code دارد، در حالی که No-code ساده‌تر و مناسب‌تر برای کاربران غیر فنی است.

این پلتفرم‌ها معمولاً برای تسریع توسعه، کاهش هزینه، افزایش بهره‌وری و توانمندسازی کاربران غیر فنی به کار می‌روند. بر اساس توضیحات مایکروسافت و کوئرا، Low-code و No-code می‌توانند زمان ساخت نرم‌افزار را به‌طور چشمگیری کم کنند و برای ساخت اپلیکیشن‌های داخلی، اتوماسیون فرایندها، فرم‌ها، داشبوردها و حتی برخی اپلیکیشن‌های وب و موبایل مناسب باشند. با این حال، هرچه نیاز به سفارشی‌سازی، منطق پیچیده، امنیت پیشرفته یا مقیاس‌پذیری بیشتر باشد، معمولاً Low-code مناسب‌تر از No-code است. بنابراین LCNC بیشتر یک طیف است تا دو دسته کاملاً جدا؛ از ابزارهای کاملاً بصری و بدون کد تا پلتفرم‌هایی که اجازه می‌دهند در کنار توسعه بصری، کد هم اضافه شود.

منابع:

• Microsoft: https://www.microsoft.com/en-us/power-platform/products/power-apps/topics/low-code-no-code/low-code-no-code-development-platforms

• میهن وب هاست: https://mihanwebhost.com/blog/articles/631/مقایسه-low-code-و-no-code-به-همراه-بررسی-ویژگی-ها-و-تفاوت-های-آنها

• Quera: https://quera.org/blog/low-code-no-code-development-explained/

• Pars BPMS: https://parsbpms.com/blog/low-code-vs-no-code