5 الگوی اساسی معماری نرم افزار

نرم افزار ضروری است. الگوهای اصلی معماری مورد استفاده برای ایجاد نرم افزاری که همه ما به آن متکی هستیم روزانه چیست؟

ارسال شده: 16 دسامبر 2020 |

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

[از مرکز معماری نمونه کارها Red Hat برای طیف گسترده ای از معماری های مرجع که می توانید استفاده کنید ، بررسی کنید.]

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

راهنماهای معماران

• کتابچه راهنمای معمار اتوماسیون
• راهنمای معمار برای زیرساخت های چند منظوره
• بدهی فنی: راهنمای ضروری رهبر فناوری اطلاعات
• مرکز معماری نمونه کارها Red Hat
• ارزیابی برنامه ریزی زیرساخت لینوکس را انجام دهید

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

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

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

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

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

الگوی مدل-کنترلر

الگوی مدل-کنترلر (MVC) یک برنامه را به سه مؤلفه تقسیم می کند: یک مدل ، یک نمای و یک کنترلر.

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

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

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

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

تصویر

زبانهای اصلی برنامه نویسی مانند JavaScript ، Python ، Java و Swift دارای چارچوب MVC برای توسعه برنامه های وب و تلفن همراه هستند. چارچوب های برنامه وب مانند Ruby on Rails و Django (برای پایتون) بر اساس این معماری ساخته شده است.

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

• درک مدل و نمای کنترل کننده با کدگذاری وحشت (2008)
• تعریف MVC از Xerox PARC اصلی نوشتن (79- 1978)

الگوی میکروسرویس

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

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

[به دنبال اطلاعات در مورد اتوماسیون سیستم هستید؟با شرکت خودکار ، یک کتاب رایگان از Red Hat شروع کنید.]

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

تصویر

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

• تعریف میکروسرویس توسط مارتین فاولر (2014)
• الگوهای معاملات توزیع شده در یک معماری میکروسرویس (2018)
• آموزش های میکروسرویس ، از جمله دستی با Kubeetes

الگوی مشتری-سرور

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

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

تصویر

منابع معماری محور رویداد

• معماری رویداد محور چیست؟
• طرح معماری مبتنی بر رویداد را بارگیری کنید
• شروع با معماری رویداد محور با استفاده از Apache Kafka
• معماری رویداد محور برای میکروسرویس

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

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

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

• مقدمه ای برای معماری استراحت
• تفاوت بین صابون و استراحت چیست؟

الگوی پاسخ دهنده کنترل کننده

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

مانند الگوی معماری مشتری-سرور ، این الگوی از دو مؤلفه تشکیل شده است: کنترلر و پاسخ دهندگان. مؤلفه کنترلر ورودی یا کار را در بین اجزای پاسخ دهنده یکسان توزیع می کند و نتیجه کامپوزیت را از نتایج حاصل از هر پاسخ دهنده ایجاد می کند.

تصویر

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

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

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

• تجزیه و تحلیل یک معماری کارشناسی ارشد برای محاسبات تکاملی توزیع شده از IEEE (2006)

الگوی لایه ای

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

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

[راه هایی را کشف کنید که معماران سازمانی بتوانند استراتژی مدرن فناوری اطلاعات را با یک استراتژی ابر ترکیبی نقشه برداری و پیاده سازی کنند.]

انواع دیگر لایه ها شامل لایه برنامه و دسترسی به داده ها یا لایه پایداری است که سپس به لایه پایگاه داده دسترسی پیدا می کند. این اجازه می دهد تا لایه پایگاه داده از هم جدا شود و شما را قادر می سازد از یک سرور اوراکل به سرور SQL تغییر دهید بدون اینکه روی لایه های دیگر تأثیر بگذارد - این امکان را برای هزینه های انتقال کمتری فراهم می کند.

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

تصویر

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

معماری ابری

• ابر ترکیبی چیست؟
• کتاب الکترونیکی: راهنمای معمار برای زیرساخت های چندگانه
• ابر ترکیبی و Kubeetes: راهنمای معماری موفق
• خدمات مدیریت شده در مقابل خدمات میزبان در مقابل خدمات ابر: تفاوت چیست؟

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

• معماری لایه ای از الگوهای معماری نرم افزار توسط مارک ریچاردز
• الگوهای معماری نرم افزاری - معماری لایه ای توسط Priyal Walpita

خط پایین

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

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