توضیح چندین موضوع در زمینه معماری نرم‌افزار

امیررضا وفائی

۱- Infrastructure as Code (IaC)

فرض کنیم که خواستار اجرا یک سایت بر روی یک سرور هستیم که با api بتوانیم پیاده‌سازی کنیم. یعنی اول باید یک سرور بخریم یا اجاره کنیم، سیستم عامل را راه‌اندازی کنیم، نرم‌افزارهای مورد نیاز اعم از دیتابیس، داکر و ... مورد نیاز اون سرور را نصب کنیم. سپس پورت‌ها، دسترسی‌ها و امنیت رو تنظیم کنیم(باید تمام دستورات مثل chmod, nano, apt install را یکی یکی اجرا کنیم). اگر قرار به اجرا تمام این موارد بر روی چندین سرور باشد، مدت زمان زیادی از برنامه‌نویس گرفته می‌شود.

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

۲- API Gateway & Service Mesh

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

موضوع API Gateway دروازه‌ی ورودی برای همه درخواست‌های خارجی به سمت سرویس‌های داخلی است که مدیریت می‌کند هر درخواست به کدام بخش فرستاده شود و اگر مشکلی وجود داشت خودش این درخواست را هندل کند. ابتدا احراز هویت می‌كند و همچنین توانایی لاگ گرفتن از درخواست را نیز دارد. از ابزارهای معروف آن میتوان به NGINX اشاره کرد.

موضوع Service Mesh یک لایه‌ شبکه‌ای است که کمک می‌کند سرویس‌های داخل سیستم (میکروسرویس‌ها) راحت‌تر، امن‌تر و هوشمندتر با هم ارتباط داشته باشند و برای ارتباط داخلی استفاده می‌شود. یک proxy تعریف می‌کند که سرویس‌ها از طریق آن با یکدیگر ارتباط می‌گیرند. از ابزارهای معروف آن میتوان به Istio اشاره کرد.

۳- CQRS (Command Query Responsibility Segregation)

دو مدل کار برای حافظه و محصولات نرم‌افزاری داریم: عملیات خواندن و نوشتن. حال اگر این دو عملیات باهمدیگر انجام شوند، باعث کاهش سرعت و پاسخگویی می‌شود. CQRS یعنی کارهای مربوط به نوشتن (تغییر دادن اطلاعات) رو از کارهای مربوط به خواندن (گرفتن اطلاعات) جدا کنیم. دو بخش اصلی داریم:

• Command: .یعنی چیزی رو عوض کن مثل کاربر جدید اضافه کن
• Query: .یعنی بگو چه اتفاقی افتاده مثل لیست کاربران رو بده

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

استفاده از آن برای سیستم‌های ساده و کوچک توصیه نمی‌شود و برای سیستم‌های بزرگ‌تر که تعداد کاربران زیادی دارند کمک زیادی می‌کند.

۴- Event-Driven Architecture (EDA)

• این مدل می‌گوید که سیستم را طوری طراحی کنیم که واحدهای مختلف فقط وقتی کاری انجام بدهند که یک رویداد خاص اتفاق بیفتد و به نوعی گوش به زنگ باشند که بعد از انجام اتفاق، واحدهای مختلف بدون درنظر گرفتن واحدهای دیگر، شروع به کار کند. یک رویداد مثل ثبت‌نام جدید کاربر را میتوان نام برد. اجزای اصلی معماری EDA:
• ۱-Event Producer : .میتوان به‌عنوان هسته نام برد که به بقیه اعلام می‌کند اتفاقی افتاده است
• ۲-Event:{event: OrderPaid, orderId: 123}.
• ۳-Event Consumer: .گیرنده یا مصرف‌کننده رویداد که با ایجاد رویداد، آن واحد شروع به‌کار می‌کند

۵- Serverless Architecture

در این معماری، مسئولیت سرور با ما نیست، یعنی نه لازم به خریدن سرور داریم و نه نگران خاموش و روشن کردن آن هستیم. معمولاً از سرویس‌هایی مثل AWS Lambd، Azure Functions و Google Cloud Functions استفاده می‌کنیم. ما کدها را می‌نویسیم و به سمت Cloud می‌فرستیم، این معماری خودش کار را انجام می‌دهد.

از مزایا این معماری می‌توان به ارزان بودن استفاده کردن اشاره کرد چون تا وقتی استفاده نکنیم هزینه‌ای ندارد و مدام روشن نیست، همچنین نیازی به مدیریت سرور نداریم و می‌توانیم تمرکز خود را روی بقیه موارد بگذاریم.

از معایب این معماری می‌توان به cold start نام برد که در این معماری پیش می‌آید و همچنین به محدودیت حافظه و زمانی اشاره کرد که نمی‌توان پروژه کامل را آپلود کرد و برای کارهای کوچیک و کوتاه مدت مناسب است.

۶- API-first Approach

در این مورد، ابتدا API رو طراحی می‌کنیم و بقیه معماری را بر اساس این موضوع جلو می‌بریم. اگر بخواهیم با مثال توضیح دهیم:

ابتدا تیم طراحی API می‌گوید که ما یک سرویس می‌خواهیم که کار مشخصی انجام دهد. سپس مستندات API را می‌نویسند (مثلا با ابزارهایی مثل Swagger یا Postman)، سپس تیم Frontend و Backend جدا جدا بر اساس API شروع به کار می‌کنند چون می‌دانند که ورودی/خروجی چه چیزی است.

بدون این معماری ممکن است Frontend مجبور باشد که منتظر Backend بماند، API در طول پروژه چند بار تغییر کند و باعث دردسر بشود، مستندات ناقص یا دیر آماده بشوند و ارتباط بین تیم‌ها سخت و پراشتباه باشد.

۷- Domain Driven Design

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

استراتژي طراحی که بکار می‌بریم:

• Collaborative Modeling: .با متخصص دامنه مدل مفهومی واقعی رو طراحی می‌کنیم
• Context Mapping: مشخص می‌کنیم هر بخش سیستم در چه مرز و محدودی‌ای است و چطور با یکدیگر ارتباط دارند
• Refactor Towards Deeper Insight: با پیشرفت پروژه، مدل دامنه رو بهبود می‌دهیم تا دقیق‌تر و ساده‌تر بشود

۸- Hexagonal architecture

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

از مفاهیم کلیدی این مورد می‌توان به موارد زیر اشاره کرد:

• ۱-هسته: شامل مدل دامنه، سرویس‌های دامنه و قوانین کسب‌وکار است که هیچ وابستگی‌ای به دیتابیس، UI یا ابزار خارجی ندارد.
• ۲-پورت‌ها: رابط‌هایی که هسته از طریق آن‌ها با دنیای بیرون حرف می‌زند که دو نوع داریم:
• پورت‌های داخل مرز و محدوده: کارهایی که از بیرون وارد می‌شوند.
• پورت‌های خارج از مرز: کارهایی که هسته به بیرون می‌سپارد، فقط تعریف interface هستند و پیاده‌سازی توسط آداپترها انجام می‌شود.
• ۳-آداپترها: اجزای خارجی که به پورت‌ها وصل می‌شوند.

۹- Event Sourcing

در Event Sourcing، به‌جای اینکه وضعیت نهایی را ذخیره کنیم، تمام اتفاقاتی که منجر به آن وضعیت شدند را ذخیره می‌کنیم. هر تغییر در سیستم به‌صورت یک رویداد ثبت می‌شود و وضعیت فعلی سیستم از روی بازپخش آن رویدادها ساخته می‌شود.

از مزایا آن میتوان به کامل‌ بودن لاگ از اتفاقات سیستم، قابلیت بازسازی هر لحظه‌ گذشته،

قابلیت audit, debugging, replay و replay-to-another-system اشاره کرد.

از این معماری می‌توان در سیستم‌هایی که نیاز به audit log دارند (بانک) برنامه‌هایی که تاریخچه کامل داده‌ها را لازم داریم، سیستم‌هایی با رفتارهای پیچیده و زیاد تغییرپذیر و

معماری‌های مبتنی بر Domain-Driven Design + CQRS استفاده کرد.

۱۰- Low-code/No-code platforms

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

از ابزارهای معروف می‌توان به OutSystems، Mendix، Microsoft PowerApps، Retool و Appian اشاره کرد.

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

در پروژه‌های واقعی ‌می‌توان معماری Microservice را مثال زد که ممکنه بخشی از آن با این پلتفرم ساخته شده باشد.

۱۱- Business Process Management Systems (BPMS)

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

از مزایا آن می‌توان به افزایش کارایی و سرعت در سازمان، کاهش خطای انسانی، امکان مانیتورینگ دقیق و گزارش‌گیری real-time، انعطاف‌پذیری برای تغییر فرآیندها و مناسب برای فرآیندهای پیچیده اشاره کرد.

کاربرد آن در مدیریت فرآیندهای منابع انسانی، فرآیندهای فروش و مالی است.

۱۲-Message Queue (such as Kafka and RabbitMQ)

این موضوع Message Queue (MQ) الگوی ارتباطی غیرهم‌زمان (Asynchronous Communication Pattern) برای سیستم‌های توزیع‌شده است که در آن، تولیدکننده (Producer) پیام‌ها را در صف قرار می‌دهد و مصرف‌کننده (Consumer) آن‌ها را پردازش می‌کند. هدف ما از این اجرا، جداسازی وابستگی زمانی و ساختاری بین کامپوننت‌ها است، به‌طوری که سیستم‌ها بتوانند مستقل از هم مقیاس‌پذیر و مقاوم باشند.

از مثال‌های واقعی، میتوان به Microserviceها اشاره کرد که هرکدام پیام تولید می‌کند (سفارش جدید) و بقیه منتظر هستند و پیام‌ را پردازش می‌کنند.

همچنین در Event Sourcing که بالا معرفی شده بود، تمامی state changes به شکل رویداد در Kafka ذخیره می‌شوند و سیستم‌ها می‌توانند با Replay کردن Eventها دوباره State را بازسازی کنند.

۱۳- Container orchestration (such as Kubernetes)

مدیریت خودکار کانتینرها که شامل اجرا، مقیاس‌دهی، شبکه، به‌روزرسانی و بازیابی از خرابی می‌شود. وقتی از Docker برای بسته‌بندی اپلیکیشن‌ استفاده می‌کنیم، برای مدیریت چندین کانتینر در محیط اجرایی (نظارت کنیم که همگی درحال اجرا باشند، اگر یک نود crash کرد، دوباره آن‌را راه‌اندازی کنیم، زمانی‌که بار زیاد شد، چندین نسخه اجرا کنیم (scaling)، میان کانتینرها ارتباط شبکه‌ امن برقرار کنیم) ، به یک هماهنگ‌کننده (orchestrator) نیاز داریم که معروف‌ترین و استانداردترین ابزار Kubernetes است.

در مفاهیم آن، Pod داریم که شامل یک یا چند کانتینر است که روی یک Node اجرا می‌شوند، مفهوم Node به معنی ماشین فیزیکی یا مجازی است که کانتینرها روی آن اجرا می‌شوند، مفهوم Cluster که به مجموعه‌ای از Nodeها که با یکدیگر کار می‌کنند، خوشه گفته می‌شود.

۱۴- Multi-Tenancy Architecture

فرض کنیم شرکت نرم‌افزاری یک اپلیکیشن آنلاین طراحی کرده است. به‌عنوان مثال ۵۰ شرکت مختلف از این اپلیکیشن استفاده می‌کنند. هر شرکت باید فقط به داده‌های خودش دسترسی داشته باشد، ولی همه از یک سیستم واحد استفاده می‌کنن. به این سبک معماری می‌گوییم Multi-Tenancy. یعنی یک سیستم همزمان به چند مشتری سرویس می‌دهد، طوری که هر کدام با مشتری‌های دیگر ارتباط نداشته باشند.

نباید داده‌ یک مشتری توسط مشتری دیگر قابل خواندن باشد که بزرگ‌ترین چالش‌ در این معماری است. باید در لایه‌های مختلف سیستم (مثل tenant isolation (API به‌درستی انجام بشود.

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

۱۵-Enterprise Integration Patterns

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

این موضوع یک زبان مشترک برای طراحی ارتباط بین سیستم‌های مستقل است. در معماری‌های مبتنی بر میکروسرویس، معماری‌های Event-Driven و سیستم‌های بزرگ سازمانی، استفاده از این الگوها باعث می‌شود که وابستگی‌ها کمتر شوند، مقیاس‌پذیری و انعطاف بالاتر برود و مدیریت خطا و مانیتورینگ ساده‌تر شود.

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

منابع:

Infrastructure as Code (IaC):

cbtnuggets

API Gateway & Service Mesh:

dzone

CQRS (Command Query Responsibility Segregation):

linkedin

Event-Driven Architecture (EDA):

redborder

Serverless Architecture:

globaldots

API-first Approach:

netsolutions

Domain Driven Design:

geeksforgeeks

Hexagonal architecture:

geeksforgeeks

Event Sourcing:

geeksforgeeks

Low-code/No-code platforms:

teamdesk.net

Business Process Management Systems (BPMS):

techtarget

Message Queue (such as Kafka and RabbitMQ):

blog.bytebytego

Container orchestration (such as Kubernetes):

metricfire

Multi-Tenancy Architecture:

geeksforgeeks

Enterprise Integration Patterns:

oneio.cloud