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

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

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

– Layered Architecture
–  Model-View-Controller Architecture
– Event-Driven Architecture
– Service-Oriented Architecture
– MicroServices Architecture
– Repository Architecture

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

Layered Architecture

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

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

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

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

در یک الگوی معماری لایه‌ای سنتی، سه سطح و چهار لایه وجود دارد. نمودار معماری زیر را در نظر بگیرید.

Layered architecture pattern

چهار لایه استاندارد به شرح زیر توصیف می‌شوند:

لایه ارائه

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

لایه منطق کسب و کار

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

لایه دسترسی به داده

این لایه مسئول برقراری ارتباط با پایگاه داده است. همچنین به عنوان لایه اثبات هویت شناخته می‌شود.

لایه ذخیره داده

این لایه فعلی، ذخیره‌ساز واقعی برای برنامه است.

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

سطوح به شرح زیر توصیف می‌شوند.

سطح ۱: سطح ارائه

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

سطح ۲: سطح برنامه

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

سطح ۳: سطح داده

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

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

Closed Layered Architecture

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

Closed Layered Architecture

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

هدف از معماری لایه‌ای بسته (Closed Layered Architecture) اطمینان حاصل کردن از جداسازی کامل لایه‌های مختلف از یکدیگر است، به این معنا که تغییراتی که در یک لایه از معماری اعمال می‌شود، تأثیری بر دیگر لایه‌ها نداشته باشد. به عبارت دیگر، لایه‌ها به طور گسترده‌ای منفصل و یکدیگر را تحت تأثیر خود نگذارند و هر لایه حداقل دانشی در مورد لایه‌های دیگر داشته باشد.

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

Opened Layered Architecture

در معماری لایه ای باز، یک لایه می تواند هر لایه پایین تر از خود را صدا بزند، در صورتی که لایه پایین تر باز باشد. در نمودار معماری لایه باز زیر را در نظر بگیرید.

Opened Layered Architecture

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

نتیجه گیری

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

تعدادی الگوی معماری در دسترس است که هر کدام مزایا و معایب خود را دارند. انتخاب یک الگوی معماری به وابستگی به سناریو یا نیازهای پروژه بستگی دارد.

Event-Driven Architecture

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

در معماری‌های مبتنی بر رویداد، سه مؤلفه اساسی وجود دارند: event producers, event routers, وevent consumers.

producer یک رویداد را منتشر می‌کنند که توسطevent routers فیلتر و سپس به event consumers ارسال می‌شود. سرویس های event producer و event consumers به صورت جداگانه پیاده سازی شده‌اند، که این اجازه را می‌دهد که آن‌ها به صورت مستقل از یکدیگر، مقیاس‌پذیر، به‌روزرسانی و اجرا شوند.

مزایای event-driven architecture