آیا تاکنون از خود پرسیده‌اید که سیستم‌های سازمانی به اصطلاح Large Scale (مقیاس بزرگ) چگونه طراحی می‌شوند؟ در یک کلام، دولوپرها و مهندسین نرم‌افزار قبل از شروع فرآیند توسعۀ یک نرم‌افزار در مقیاس بزرگ، ابتدا باید یک معماری (Architecture) مناسب برای آن انتخاب کنند که این معماری باید عملکرد و کیفیت مورد انتظار از نرم‌افزار را در اختیار ایشان قرار دهد. از همین روی، قبل از شروع طراحی و توسعهٔ نرم‌افزار نیاز است تا دولوپرها با انواع معماری نرم‌افزار آشنایی داشته باشند و این همان چیزی است که در ادامه شرح خواهیم داد.

الگوی معماری چیست؟

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

الگوی Layered

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

لایۀ Presentation (با عنوان لایه UI نیز شناخته می‌شود.)
لایۀ Application (با عنوان لایه Service نیز شناخته می‌شود.)
لایۀ Business Logic (با عنوان لایه Domain نیز شناخته می‌شود.)
لایه Data Access (با عنوان لایه Persistence نیز شناخته می‌شود.)

لازم به ذکر است که الگوی معماری Layered برای طراحی معماری اپلیکشن‌هایی به شرح زیر کاربرد دارد:

اپلیکیشن‌های دسکتاپ
وب‌اپلیکیشن‌های مربوط به تجارت الکترونیک

الگوی Client-Server

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

الگوی Master-Slave

این الگوی معماری شامل دو بخش است که عبارتند از اصطلاحاً Master و Slave. کامپوننت مَستر تَسک‌ها را در میان تعداد مشخصی از کامپوننت‌های اِسلِیو توزیع می‌کند؛ سپس هر کدام از کامپوننت‌های اِسلِیو نتایجی را برمی‌گردانند و در ادامه کامپوننت مَستر از نتایج به‌ دست‌ آمده از کامپوننت‌های اِسلِیو، نتیجۀ کلی را محاسبه خواهد کرد. به طور کلی، این الگوی معماری را می‌توان برای مواردی به شرح زیر مورد استفاده قرار داد:

در Database Replication که در آن داده‌ها از یک دیتابیس در یک کامپیوتر یا سرور به یک دیتابیس در سرور دیگر کپی می‌شوند به‌ طوری که تمام کاربران به اطلاعات یکسانی دسترسی دارند که نتیجه یک دیتابیس توزیع‌شده است که در آن کاربران می‌توانند به داده‌های مربوط به تَسک‌های خود -بدون دخالت در کار سایر کاربران- دسترسی پیدا کنند. در این روش، دیتابیس اصلی به عنوان مَستر (منبع) در نظر گرفته می‌شود و دیتابیس‌های فرعی با آن سینک می‌شوند.
کامپوننت‌های فرعی متصل به یک Bus در یک سیستم کامپیوتری؛ برای مثال درایو اصلی و درایوهای فرعی (Bus در سیستم‌های کامپیوتری مجموعه‌ای از کانکشن‌های فیزیکی از جمله کابل‌ها و غیره است که می‌توان آن‌ها را با چندین کامپوننت سخت‌افزاری به‌ منظور برقراری ارتباط با یکدیگر، به اشتراک گذاشت. هدف Bus کاهش تعداد مسیرهای فیزیکی مورد نیاز برای ارتباط بین کامپوننت‌ها است.)

الگوی Pipe-filter

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

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

الگوی Broker

این الگو برای ساخت سیستم‌های توزیع‌شده با کامپوننت‌های به اصطلاح Decoupled (جدا از هم) مورد استفاده قرار می‌گیرد. این کامپوننت‌ها می‌توانند به‌واسطۀ سرویس‌های ریموت با یکدیگر ارتباط برقرار کنند. در واقع، کامپوننت بروکر مسئول هماهنگی برای برقراری ارتباط بین کامپوننت‌های سازنده است؛ در همین راستا، توانایی‌ها، قابلیت‌ها و تَسک‌هایی که سرورها از عهدهٔ آن‌ها برمی‌آیند در اختیار بروکر قرار گرفته، سپس کلاینت‌ها برای دستیابی به سرویس مد نظر خود، برای بروکر یک ریکوئست (درخواست) می‌فرستند و در نهایت هم بروکر کلاینت را به سرویس مد نظر ریدایرکت می‌کند. از این الگوی معماری در طراحی اپلیکیشن‌هایی ارتباطی همچون Apache ActiveMQ ،Apache Kafka ،RabbitMQ و JBoss Messaging استفاده می‌شود.

الگوی Peer-to-Peer

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

شبکه‌های به اشتراک‌گذاری فایل مانند Gnutella و G2
پروتکل‌های مالتی‌مدیا مانند P2PTV و PDTP

💎 بیشتر بدانید: سه نوع از معماری CQRS که هر معمار نرم افزاری باید بداند

الگوی معماری Event-Bus

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

Event Source
Event Listener
Channel
Event Bus

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

توسعۀ اپلیکیشن‌های اندرویدی
سرویس‌های ارسال نوتیفیکیشن

الگوی معماری Model-View-Controller

این الگو که به اختصار MVC نامیده می‌شود، معماری اپلیکیشن‌های تعاملی را به سه قسمت تقسیم می‌کند که عبارتند از:

Model: شامل قابلیت‌های اصلی اپلیکیشن و داده‌ها است (در واقع، مدل مسئول کاری است که اپلیکیشن به خاطر آن توسعه یافته است.)
View: مسئولیت نمایش دیتای مورد نیاز و رابط کاربری اپلیکیشن به کاربر را بر عهده دارد (در برخی اپلیکیشن‌ها ممکن بیش از یک ویو برای کاربران تعریف شود.)
Controller: مسئولیت هَندل کردن داده‌های ورودی کاربران و برقراری ارتباط مابین مدل و ویو را بر عهده دارد.

الگوی معماری ام‌وی‌سی موجب جداسازی کامپوننت‌های فوق در یک اپلیکیشن می‌شود؛ به عبارت دیگر، این الگوی معماری موجب جدا شدن روش‌های به‌کارگیری دیتا در داخل اپلیکیشن از روش‌های ارائۀ دیتا و دریافت آن‌ها از کاربران می‌شود و همین مسئله نیز موجب کاهش پیچیدگی و سهولت توسعۀ اپلیکیشن خواهد شد و این امکان را برای دولوپرها فراهم می‌آورد تا بتوانند به شیوه‌ای مؤثر، از سورس‌کد اپلیکیشن استفادۀ مجدد داشته باشند (برای آشنایی بیشتر با الگوی معماری MVC، به آموزش مقدمه‌ای بر معماری سه‌لایهٔ MVC نرم‌افزاری مراجعه کنید.) به طور کلی، از این الگوی معماری می‌توان برای طراحی معماری وب اپلیکیشن‌ها در اکثر زبان‌های برنامه‌نویسی مثل PHP و غیره استفاده کرد (لازم به ذکر است که سایت سکان آکادمی با این معماری طراحی شده است.)

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

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

Blackboard: یک حافظه گلوبال ساختاریافته که حاوی آبجکت‌های مد نظر است.
Knowledge Source: شامل ماژول‌های اختصاصی پردازش‌کنندۀ دیتا است.
Control Component: هر یک از ماژول‌ها را انتخاب، پیکربندی و اجرا می‌کند.

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

تشخیص گفتار
شناسایی خودرو و ردیابی آن‌ها
شناسایی ساختار پروتئین!
تفسیر سیگنال‌های اشیاء موجود در زیر آب!

الگوی Interpreter

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

زبان‌های مربوط به دیتابیس (همچون SQL)
زبان مورد استفاده برای توصیف پروتکل‌های ارتباطی

لازم به ذکر است که به غیر از موارد فوق، می‌توان به معماری میکروسرویس هم اشاره کرد که علاقمندان می‌توانند برای کسب اطلاعات بیشتر، به مقالهٔ میکروسرویس (Microservice) چیست؟ مراجعه نمایند.

جمع‌بندی

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

معرفی الگوهای متداول معماری نرم‌افزار