الگوی معماری (Architecture Pattern) یک راه حل کلی و قابل استفاده مجدد (reusable) برای یک مشکل معمول در معماری نرم افزار در یک زمینه خاص است.

A pattern is a solution to a problem in a context

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

میخواهیم انواع معماری نرم افزار زیر را با هم مورد بررسی قرار دهیم:

• Layered Architecture
• Pipe and Filter
• Client Server
• Model View Controller
• Event Driven Architecture
• Microservices Architecture

Layered Architecture

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

• Presentation
• Business
• Persistence
• Database

Context

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

Problem

این نرم افزار باید به گونه‌ای تقسیم بندی شود که ماژول‌ها بتوانند با تعامل کم بین قطعات، پشتیبانی از قابلیت حمل (protabality)، تغییرپذیری (modifiability) و استفاده مجدد (reuse)، جداگانه ساخته شوند و تکامل یابند.

Solution

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

• اولین مفهوم این است که هر یک از لایه‌ها نقش و مسئولیت خاصی دارند. به عنوان مثال ، لایه presentation مسئولیت رسیدگی به رابط کاربری است. زیرا این تفکیک در درون معماری لایه‌ای ساختن نقش ها و مسئولیت های موثر را آسان می کند.
• در مفهوم دوم ، الگوی معماری لایه‌ای یک معماری از نظر فنی تقسیم شده در مقابل یک معماری تقسیم شده دامنه است. آنها گروههایی از componentها هستند و نه بر اساس دامنه.
• آخرین مفهوم این است که هر یک از لایه‌ها در معماری لایه‌ای به صورت بسته یا باز مشخص شده‌اند. یک لایه بسته به این معنی است که یک درخواست از لایه‌ای به لایه دیگر منتقل می شود، باید از لایه زیر آن عبور کند تا به لایه بعدی آن برسد. این درخواست نمی تواند از هیچ لایه‌ی دیگری بگذرد.

Weakness

لایه‌ها به پنالتی عملکرد کمک می کنند. این الگو خود را به برنامه‌های با کارایی بالا (high-performance) نمی‌رساند زیرا عبور از چندین لایه معماری برای انجام درخواست تجاری کارآمد نیست.

Usages

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

Multi-Tier Pattern

Context

در استقرار توزیع شده (distributed deployment)، اغلب نیاز به توزیع زیرساخت‌های یک سیستم در زیرمجموعه‌های متمایز است.

Problem

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

Solution

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

Weakness

هزینه قابل توجه و پیچیده

Usages

در سیستم های توزیع شده استفاده می شود.

معماری نرم افزار Pipe and Filter

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

Context

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

Problem

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

Solution

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

در این سبک چهار نوع فیلتر وجود دارد که به شرح زیر است:

• تولید کننده (source): نقطه شروع یک فرآیند.
• ترانسفورماتور (map): تحولی را در بعضی یا کل داده ها انجام می دهد.
• تستر (reduce): یک یا چند معیار را آزمایش می کند.
• مصرف کننده (sink): نقطه پایان.

Weakness

به دلیل ویژگی تحول آفرین آنها ، برای سیستم های تعاملی (interactive systems) گزینه مناسبی نیست.

parsing بیش از حد و unparsing منجر به کاهش عملکرد و افزایش پیچیدگی در نوشتن فیلترها می شود.

Usages

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

Client Server

Context

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

Problem

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

Solution

در یک معماری Client-Server ، اجزا و اتصالات رفتار خاصی دارند.

• کامپوننت ها ، “مشتری” نامیده می شوند ، درخواست ها را به یک component به نام “سرور” ارسال می کنند و منتظر پاسخ می مانند.
• یک سرور درخواستی از مشتری دریافت می کند و پاسخ را برای آن ارسال می کند.

Weakness

سرور می تواند یک گلوگاه عملکرد (performance bottleneck) و یک نقطه خرابی (single point of failure) باشد.

تصمیم گیری در مورد محل قرارگیری عملکرد (در سرویس گیرنده یا در سرور) اغلب پیچیده و هزینه بر است که پس از ساخت سیستم تغییر می کند.

Usages

ما می توانیم از سبک سرویس گیرنده سرویس دهنده برای مدل سازی بخشی از سیستم استفاده کنیم که دارای بسیاری از اجزای ارسال کننده درخواست (مشتری) به  component دیگری (سرور) است که خدمات ارائه می دهد: برنامه های آنلاین مانند ایمیل ، اشتراک اسناد و خدمات بانکی.

Model View Controller

Context

رابط کاربری معمولاً قسمت تغییر یافته اغلب برنامه های تعاملی است. کاربران اغلب مایلند از دیدگاه های مختلف مانند نمودار میله ای یا نمودار دایره ای به داده ها نگاه کنند. این نمایش ها باید هر دو وضعیت فعلی داده ها را منعکس کنند.

Problem

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

و چگونه می توان هنگام تغییر داده های برنامه اصلی ، چندین نمایش از رابط کاربری ایجاد ، حفظ و هماهنگ کرد؟

Solution

الگوی Model-View-Controller (MVC) عملکرد برنامه را به سه نوع component به شرح زیر جدا می کند:

• Model : مدلی که حاوی داده های برنامه است.
• View : نمایی که بخشی از داده های اساسی را نشان می دهد و با کاربر تعامل دارد.
• Controller : یک کنترل کننده ، که میان مدل و نما واسطه است و اعلان های تغییرات وضعیت را مدیریت می کند.

Weakness

پیچیدگی ممکن است برای رابط های کاربری ساده ارزش آن را نداشته باشد.
انتزاعات Model – View – Controller برای برخی از مجموعه ابزارهای رابط کاربر مناسب نیست.

Usages

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

Context

برای رسیدگی به رویدادهای مستقل همزمان (asynchronous) برنامه های همزمان تولید شده به روشی که بتواند با افزایش تقاضا افزایش یابد ، منابع محاسباتی و اطلاعاتی باید تهیه شود.

Problem

سیستم های توزیع شده ای را بسازید که بتوانند پیام های ورودی ناهمزمان مرتبط با یک رویداد را سرویس کنند و می توانند از کوچک و ساده به بزرگ و پیچیده تبدیل شوند.

Solution

برای پردازش رویدادها ، فرایندها / پردازش های رویداد مستقل (independent event processes) را به کار گرفته میشود. eventهای ورودی در صف قرار می گیرند. یک برنامه ریز رویدادها را از صف بیرون می کشد و بر اساس خط مشی برنامه ریزی آنها را در کنترل کننده رویداد مناسب توزیع می کند.

Weakness

عملکرد و بازیابی خطا ممکن است مشکلاتی باشد.

Usages

یک برنامه تجارت الکترونیکی (e-commerce application) که از این روش استفاده می کند به شرح زیر عمل می کند:
سرویس سفارش یک سفارش در حالت معلق ایجاد می کند و یک رویداد OrderCreated را منتشر می کند.

• Customer Service رویداد را دریافت می کند و سعی می کند اعتبار آن سفارش را رزرو کند. سپس یا یک رویداد Credit Reserve یا یک رویداد CreditLimitExceded را منتشر می کند.
• سرویس سفارش رویداد را از خدمات مشتری دریافت می کند و وضعیت سفارش را به تایید یا لغو تغییر می دهد

Microservices Architecture

Context

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

Problem

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

Solution

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

Weakness

سیستم ها باید برای تحمل خرابی خدمات (tolerate service failures) که به نظارت بیشتر سیستم نیاز دارند ، طراحی شوند. برنامه کاری و خدمات رویدادی سربار.

ما همچنین به حافظه بیشتری نیاز داریم.

Usages

بسیاری از موارد استفاده برای معماری Microserviceها قابل اجرا است ، به ویژه مواردی که شامل یک pipeline داده گسترده هستند. به عنوان مثال ، یک سیستم مبتنی بر microservice برای سیستم گزارش دهی در فروشگاه های خرده فروشی یک شرکت ایده آل است. هر مرحله در فرآیند آماده سازی داده ها توسط یک سرویس خرد انجام می شود: جمع آوری داده ها ، پاکسازی ، عادی سازی ، غنی سازی ، تجمیع ، گزارش دهی و غیره.

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

منبع : GitConnected