معماری نرم‌افزار

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

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

معماری نرم افزار چیست؟

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

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

تاریخچه معماری نرم افزار به زبان ساده

مفهوم معماری نرم‌افزار در اواخر دهه ۶۰ میلادی پدیدار شد؛ زمانی که محققان علوم کامپیوتر روی اهمیت ساختار یک سیستم نرم‌افزاری و تعریف و پیاده‌سازی صحیح آن پافشاری کردند. از آن زمان تا دهه ۹۰ میلادی، تلاش‌ها و تحقیقات مختلفی برای تعریف این مفهوم انجام شد و در نهایت، مفاهیم سبک‌های Software Architecture، متدهای معماری نرم‌افزار و … ایجاد شدند.

سبک‌ها و الگوهای معماری نرم‌افزار

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

سبک معماری (Architectural Styles)، در واقع نام‌گذاری سیستم‌های نرم‌افزاری با توجه به ویژگی‌هایی است که آن‌ها را از یکدیگر متمایز می‌کند. ما می‌توانیم از سیستم‌هایی با سبک معماری یکسان، ویژگی‌ها و رفتارهای مشابهی را در معماری انتظار داشته باشند. علاوه بر این، سبک معماری نرم‌افزار با مجموعه‌ای از دستورالعمل‌ها، به ما در تصمیم‌گیری برای سیستم کمک می‌کند.

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

تفاوت سبک و الگوی معماری

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

انواع سبک و الگوهای معماری نرم‌افزار

در این بین بعضی از سبک‌ها (Styles) و الگوهای معماری نرم‌افزار (Software Architecture Patterns) از بقیه کاربردی‌تر و به همین خاطر، شناخته‌شده‌ترند. معروف‌ترین سبک‌ها و الگوهای معماری عبارتند از:

معماری Layered

معماری لایه‌ای (Layered) یکی از رایج‌ترین سبک‌های معماری نرم‌افزار است. ایده اصلی در این سبک معماری، این است که ماژول‌ها یا مولفه‌هایی با عملکردهای مشابه در لایه‌های افقی سازمان‌دهی شوند. در نتیجه، هر لایه نقش خاصی را در برنامه ایفا می‌کند.

به طور معمول در سیستم‌های مختلف، ۴ لایه وجود دارد:

• لایه نمایشی (Presentation Layer) که همان ظاهر سیستم است (مانند UI)،
• لایه اپلیکیشن (Application Layer) که لایه ارائه خدمات است،
• لایه کسب و کار (Business Layer) یا لایه دامنه (Domain) که قوانین کسب و کار را در محصول پیاده می‌کند،
• لایه دسترسی به داده (Data Access Layer) که به پایداری سیستم کمک می‌کند و وظیفه ارتباط با پایگاه داده و منابع خروجی داده را دارد.

معماری مونولیتیک (Monolithic)

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

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

معماری میکروسرویس (Microservices)

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

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

معماری شی‌گرا (Object-oriented)

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

معماری Client-server

معماری Client-Server مدلی است که در آن مشتری، کاربر یا حتی یک اپلیکیشن که به عنوان Client یا سرویس‌گیرنده شناخته می‌شود، درخواستی را به سرور (سرویس‌دهنده) ارسال می‌کند و سرور این درخواست را با ارسال داده یا سرویس درخواستی پاسخ می‌دهد.

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

معماری Peer-to-Peer

در الگوی معماری Peer-to-Peer که با نام‌های همتا به همتا، نظیر به نظیر یا به صورت خلاصه P2P شناخته می‌شود، هر جزء از سیستم همتا یا Peer نام دارد. یک همتا می‌تواند به عنوان یک مشتری، یک سرور یا هر دو باشد و نقش خود را به صورت پویا در طول زمان تغییر دهد. یک همتا، به عنوان مشتری می‌تواند از سایر همتایان شبکه درخواست خدمات داشته باشد و به عنوان یک سرور، می‌تواند به سایر همتایان سرویس بدهد.

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

الگوی معماری MVC

الگوی معماری Model-View-Controller (به اختصار MVC) یک برنامه را به سه بخش تقسیم می‌کند. بخش مدل (Model) شامل داده‌های برنامه و عملکردهای اصلی است. بخش نمایش (View) داده‌ها را نمایش می‌دهد و با کاربر تعامل دارد و بخش کنترل کننده (Controller) ورودی کاربر را کنترل می‌کند و به عنوان رابط بین Model و View عمل می‌کند.

معماری Event-Driven

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

در معماری Event-Driven، رویدادها توسط اجزای مختلف یک سیستم مثل رابط کاربری یا سرویس پشتیبانی تولید می‌شوند. آن‌ها سپس برای سایر اجزای سیستم ارسال می‌شوند هر جزء می‌تواند در صورت نیاز، روی یک رویداد عملیات انجام دهد.

معماری میکروکرنل (Microkernel)

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

عملکرد اصلی سیستم در MicroKernel که یک سیستم مرکزی است که تنها ضروری‌ترین خدمات مورد نیاز برای اجرای سیستم را ارائه می‌دهد، پیاده‌سازی شده است.

اهداف معماری

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

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

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

اصول معماری نرم افزار S.O.L.I.D

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

در ادامه اصول SOLID را به تفکیک بررسی می‌کنیم.

۱. Single Responsibility (مسئولیت واحد)

این اصل به تک مسئولیتی بودن سرویس‌ها اشاره دارد و می‌گوید که هر سرویس، باید تنها یک هدف داشته باشد.

۲. Open-Closed Principle (اصل باز-بسته)

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

۳. Liskov Substitution Principle (اصل جایگزینی لیسکوف)

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

۴. Interface Segregation Principle (اصل تفکیک رابط)

میکروسرویس‌های یک نرم‌افزار که مستقل و در ارتباط هستند، نباید رابط‌های حشو و اضافی داشته باشند.

۵. Dependency Inversion Principle (اصل وارونگی وابستگی)

ماژول‌های سطح بالا نباید وابسته به ماژول‌های سطح پایین باشند و تغییرات در سطوح بالاتر نباید روی سطوح پایین‌تر تاثیر بگذارد. به عبارتی هرچه سطح سیستم بالاتر باشد، وابستگی کمتر می‌شود.

معماری در نرم‌افزار تا چه اندازه مهم است؟

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

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

تفاوت الگوی معماری و الگوی طراحی

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

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

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

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

سخن پایانی

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