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

معمار کیست

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

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

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

یک معماری خوب، باید موارد زیر را در نظر گرفته باشد:

• توسعه
• استقرار
• عملکرد
• نگهداری

توسعه

استقرار

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

عملکرد

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

نگهداری

بیشترین هزینه در ایجاد یک نرم افزار را دارد. شامل موارد زیر:

1. افزودن ویژگی جدید
2. رفع مشکلات و باگ‌ها

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

راه حل:

• تقسیم سیستم به چند کامپوننت مجزا
• ایجاد یک قالب مشخص برای کامپوننت‌ها، که کامپوننت‌ها برای برنامه‌نویسان یک ساختار مشخص و مشابه داشته باشند. در آینده بهتر میتوانند مکان لازم برای تغییر را پیدا کنند.

نرم افزار از دو بخش ۱-ساختار و ۲-رفتار تشکیل شده است.

واژه Soft در نرم‌افزار به قابلیت تغییر آن اشاره می‌کند. برای این منظور نیاز که به موارد زیر توجه داشت:

• ساختار
• نحوه قرارگیری کامپوننت‌ها
• نحوه ارتباط کامپوننت‌ها

همچنین بخش‌بندی نرم‌افزار از منظر دیگر:

• سیاست‌ها - policy
• قوانین کسب و کار
• کارایی‌ها
• جزییات - detail
• بخش‌های توسعه
• برنامه‌نویسان
• نحوه پیاده‌سازی
• نوع دیتابیس
• و …

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

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

Plugin Architecture

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

مرزبندی میان مولفه‌ها

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

1. ایجاد نظم در سطح کد منبع - بدون تقسیم کردن سیستم
   در زمان پیاده‌سازی، صدا زدن توابع از سطوح پایین‌تر به سمت سطوح بالاتر انجام می‌شود. سیستم یکپارچه است بنابراین ارتباطات سریع و کم‌هزینه هستند.
   - پردازنده: مشترک
   - فضای حافظه: مشترک
   - ارتباط میان بخش‌ها: Function call
2. ایجاد مولفه‌های استقرار
   مولفه‌ها به صورت برنامه های قابل اجرا(Binary) ایجاد می‌شود. شبیه سیستم یکپارچه، ارتباطات سریع و کم‌هزینه هستند.
   - پردازنده: مشترک
   - فضای حافظه: مشترک
   - ارتباط میان بخش‌ها: Function call
3. فرایند محلی - Local Process
   - پردازنده: مشترک
   - فضای حافظه: مجزا
   - ارتباط میان بخش‌ها: Socket, Message quesues
4. سرویس‌ها - Services
   قوی‌ترین سطح مرز بندی را دارد. هر سرویس یک فرایند هست. سرعت ارتباط پایین است بنابراین نیاز است تا جای ممکن میزان ارتباطات را کاهش داد.
   - پردازنده: مشترک/مجزا
   - فضای حافظه: مجزا
   - ارتباط میان بخش‌ها: از طریق شبکه(سرعت پایین)