وقتی صحبت از ساخت نرمافزار میشود، اغلب تمرکز ما روی زبان برنامهنویسی، فریمورک یا دیتابیس است. اما تجربه نشان داده است که بزرگترین عامل موفقیت یا شکست یک سیستم نرمافزاری، معماری آن است، نه ابزارهایی که در آن استفاده میکنیم.
در این مقاله، بهعنوان اولین قدم از سری مقالات معماری Microservices، ابتدا باید به یک سؤال اساسی پاسخ دهیم:
معماری نرمافزار چیست و چرا باید از همان روزهای اول به آن فکر کنیم؟
معماری نرمافزار (Software Architecture) مجموعهای از تصمیمات کلان درباره ساختار سیستم است؛ تصمیماتی که تعیین میکنند:
سیستم از چه اجزایی تشکیل شده است
این اجزا چگونه با هم ارتباط دارند
هر بخش چه مسئولیتی دارد
سیستم چگونه توسعه، نگهداری و مقیاسپذیر میشود
بهصورت سادهتر:
معماری نرمافزار، اسکلت اصلی سیستم است؛ چیزی که تغییر آن بعد از بزرگ شدن پروژه، بسیار پرهزینه و گاهی غیرممکن است.
یکی از اشتباهات رایج، یکی دانستن Architecture و Design است.
معماری، مسیر را مشخص میکند؛ طراحی، جزئیات حرکت در این مسیر را.
شاید در پروژههای کوچک، اهمیت معماری چندان به چشم نیاید، اما با رشد سیستم، مشکلات معماری خودشان را نشان میدهند.
توسعه هر فیچر جدید سختتر میشود
دیپلوی سیستم ریسک بالایی دارد
تغییر یک بخش، بخشهای دیگر را میشکند
تیم توسعه دچار اصطکاک میشود
سیستم بهسختی مقیاسپذیر است
در مقابل، یک معماری مناسب باعث میشود:
توسعه سریعتر و امنتر انجام شود
سیستم قابل نگهداری باقی بماند
تیمها مستقلتر کار کنند
هزینه تغییرات در آینده کاهش یابد
یکی از رایجترین و قدیمیترین معماریها، معماری لایهای است.
Controller Service Repository Database
ساده و قابل فهم
مناسب پروژههای کوچک و متوسط
یادگیری آسان
وابستگی زیاد لایهها به هم
سختی مقیاسپذیری در پروژههای بزرگ
تبدیل شدن تدریجی به Monolith سنگین
بسیاری از سیستمهایی که امروز نیاز به Microservices پیدا کردهاند، با همین معماری شروع شدهاند.
فرض کنید یک استارتاپ با یک سیستم ساده شروع میکند:
ثبتنام کاربر
سفارش
پرداخت
در ابتدا:
همه چیز در یک پروژه
یک دیتابیس
یک تیم کوچک
اما با رشد محصول:
تیم بزرگتر میشود
فیچرهای مالی پیچیدهتر میشوند
حجم کاربران افزایش پیدا میکند
در این مرحله، معماری اولیه دیگر پاسخگو نیست و مشکلاتی مثل:
Deploy پرریسک
کدهای بهشدت وابسته
باگهای زنجیرهای
شروع میشوند.
اینجاست که مفاهیمی مثل Monolith و Microservices وارد بازی میشوند.
از نظر تئوری بله، اما در عمل:
پرهزینه است
زمانبر است
نیازمند تجربه بالا است
معمولاً با ریسک بالا همراه است
به همین دلیل، انتخاب معماری مناسب در زمان مناسب اهمیت حیاتی دارد.
در این مقاله به موارد زیر پرداختیم:
معماری نرمافزار چیست
چرا مهمتر از ابزارهاست
تفاوت Architecture و Design
معماری لایهای چه مزایا و معایبی دارد
چرا با رشد سیستم، معماری به چالش کشیده میشود
در مقاله بعدی، وارد یکی از مهمترین مباحث میشویم:
Monolithic Architecture چیست و چرا هنوز هم در بسیاری از پروژهها بهترین انتخاب است؟
