معرفی و تعریف
طراحی سیستم و معماری نرمافزار، توانایی تبدیل یک مسئله یا نیازمندی کسبوکار به اجزای فنی، قراردادهای ارتباطی، مدل داده، جریانهای پردازش و تصمیمهای اجرایی است. فردی که این مهارت را دارد، مشخص میکند هر بخش سامانه چه مسئولیتی دارد، داده چگونه جابهجا میشود و اجزا چگونه در برابر خطا، رشد کاربران یا تغییر نیازمندیها رفتار میکنند.
معماری نرمافزار فقط انتخاب الگوی مایکروسرویس یا یک فناوری محبوب نیست. هدف آن انتخاب ساختاری متناسب با مسئله است. ساختاری که بتوان آن را توسعه داد، آزمود، پایش کرد و در آینده تغییر داد. در این فرایند، تصمیمهایی مانند انتخاب پایگاه داده، شیوه کش کردن داده، مرزبندی سرویسها، طراحی «رابط برنامهنویسی کاربردی» (API) و مدیریت خطا باید با محدودیتهای واقعی محصول هماهنگ باشند.
مهندسان نرمافزار، توسعهدهندگان بکاند، رهبران فنی و معماران نرمافزار از این مهارت استفاده میکنند. عمق موردنیاز به سطح شغلی، نوع محصول و دامنه مسئولیت بستگی دارد. توسعهدهنده جونیور معمولاً باید اجزای یک قابلیت و وابستگیهای آن را بفهمد. توسعهدهنده میانی بتواند طراحی یک سرویس یا جریان داده را پیشنهاد دهد و فرد ارشد بتواند تصمیمهای معماری و بدهبستانهای مقیاسپذیری، هزینه، پیچیدگی و قابلیت نگهداری را برای تیم و ذینفعان توضیح دهد.
اهمیت و کاربردها
چرا این مهارت مهم است؟
بسیاری از مسائل دشوار توسعه نرمافزار با نوشتن یک تابع حل نمیشوند. هنگامی که یک قابلیت به چند سرویس، دادههای مشترک، کاربران همزمان، یکپارچهسازی بیرونی یا الزامهای دسترسپذیری وابسته است، کیفیت طراحی اولیه بر سرعت توسعه و هزینه تغییرات بعدی اثر میگذارد.
در نقشهایی مانند مهندس نرمافزار، توسعهدهنده بکاند، توسعهدهنده فولاستک، سرپرست فنی و معمار نرمافزار، میزان مسئولیت طراحی سیستم به سطح شغلی، اندازه تیم و حساسیت محصول بستگی دارد. یک تیم کوچک ممکن است به طراحی ساده و قابلاجرا نیاز داشته باشد، در حالی که محصولی با کاربران زیاد یا تراکنشهای حساس، تحلیل دقیقتر ظرفیت، خطا و بازیابی را میطلبد.
این مهارت به شما کمک میکند در گفتوگوهای فنی، انتخاب خود را با معیارهای روشن دفاع کنید. پاسخ خوب معماری، «بهترین فناوری» را اعلام نمیکند؛ توضیح میدهد چرا یک راهحل با حجم داده، تیم، بودجه، زمان تحویل و ریسکهای همان مسئله سازگارتر است.
کاربردها
-
طراحی سرویس ثبت و پیگیری سفارش
مرزبندی مسئولیتهای سفارش، پرداخت، موجودی و ارسال، همراه با تعیین وضعیتهای سفارش و رفتار سامانه هنگام ناموفقبودن پرداخت یا تکرار درخواست.
-
طراحی API برای اپلیکیشن و پنل مدیریتی
تعریف قراردادهای API، احراز هویت، نسخهبندی، اعتبارسنجی ورودی و شیوه بازگرداندن خطا، بهگونهای که چند کلاینت بتوانند پایدار از سرویس استفاده کنند.
-
مدیریت بار خواندن بالا
انتخاب کش مانند Redis، ایندکس پایگاه داده مانند PostgreSQL، صف پیام مانند Apache Kafka یا جداسازی مسیرهای خواندن و نوشتن برای بخشی که درخواستهای پرتکرار دارد.
-
تجزیه سامانه یکپارچه در حال رشد
شناسایی مرزهای منطقی ماژولها یا سرویسها و پرهیز از شکستن زودهنگام سامانه به مایکروسرویسهایی که هزینه عملیاتی ناموجه دارند.
-
طراحی پردازشهای غیرهمزمان
انتقال کارهای زمانبر مانند ارسال اعلان، تولید گزارش یا پردازش فایل به صف و worker، همراه با راهکار تکرار امن، ثبت خطا و مشاهدهپذیری.
-
بازبینی تصمیم معماری پیش از توسعه
ثبت گزینهها، محدودیتها و پیامدهای هر تصمیم تا تیم بتواند پیش از پیادهسازی درباره هزینه نگهداری، امنیت و ظرفیت سامانه توافق کند.
ابزارهای مرتبط
پیشنیازها
شروع این مهارت با دانستن پیشنیازهای زیر هموارتر میشود.
- تجربه پیادهسازی و نگهداری دستکم یک پروژه نرمافزاری چندبخشی
- توانایی خواندن مستندات فنی انگلیسی
- آشنایی با برنامهنویسی شیءگرا برای توسعهدهندگانی که در پروژههای شیءگرا کار میکنند؛ تجربه معادل در هر سبک برنامهنویسی دیگر نیز قابلقبول است.
مسیر یادگیری طراحی سیستم و معماری نرمافزار
-
۲۵ ساعت
نیازمندی را به سناریو و محدودیت فنی تبدیل کنید
برای یک محصول فرضی، کاربران، عملیات اصلی، دادههای ورودی و خروجی و سناریوهای خطا را بنویسید. میان نیازمندیهای عملکردی، مانند ثبت سفارش و نیازمندیهای غیرعملکردی، مانند زمان پاسخ، دسترسپذیری و امنیت، تفاوت بگذارید. پیش از انتخاب فناوری، فرضهای خود درباره حجم استفاده و محدودیتهای محصول را آشکار کنید.
برای توسعهدهندهای که پیشنیازهای این صفحه را دارد، رسیدن به سطح کاربردی معمولا به حدود ۱۴۰ تا ۲۲۰ ساعت مطالعه و تمرین نیاز دارد؛ اگر هفتهای ۱۰ ساعت تمرین کنید، این بازه تقریباً ۴ تا ۶ ماه زمان میبرد. برآورد ۱۸۰ ساعت، نقطه میانی این بازه است و زمان قطعی یادگیری نیست.
-
۳۰ ساعت
اجزا، مسئولیتها و قراردادهای سامانه را مرزبندی کنید
یک سامانه را به کلاینت، API، منطق کسبوکار، ذخیرهسازی داده و سرویسهای بیرونی تقسیم کنید. برای هر جزء، مسئولیت، ورودی، خروجی و وابستگیها را مشخص کنید. نمودار زمینه، نمودار اجزا و نمودار جریان یک درخواست را رسم کنید و از ایجاد اجزایی با مسئولیت مبهم پرهیز کنید.
-
۳۵ ساعت
داده و ارتباط بین اجزا را طراحی کنید
مدل داده، کلیدهای اصلی و روابط مهم را طراحی کنید. برای تمرین، یک مدل رابطهای را در PostgreSQL پیادهسازی کنید و اثر ایندکسها را بر مسیرهای پرتکرار بررسی کنید. تفاوت ارتباط همزمان و غیرهمزمان را درک کنید و برای هر جریان، زمان مناسب استفاده از درخواست HTTP، صف پیام مانند Apache Kafka یا پردازش پسزمینه را توضیح دهید. مفاهیم سازگاری داده، تکرار درخواست، ترتیب پیام و مدیریت خطا را با مثال تمرین کنید.
-
۳۵ ساعت
بدهبستانهای مقیاسپذیری و قابلیت اطمینان را تحلیل کنید
مفاهیم مقیاسپذیری افقی و عمودی، کش، تکثیر داده، توزیع بار، محدودسازی نرخ و صف را یاد بگیرید. برای یک سناریوی مشخص، گلوگاهها و نقطههای تکخرابی را شناسایی کنید. نقش Redis را برای دادههای خواندنی پرتکرار و هزینه ناسازگاری کش بررسی کنید. همچنین مشخص کنید آیا بستهبندی سرویس با Docker و استقرار و مقیاسدهی آن با Kubernetes واقعاً با اندازه تیم و نیاز عملیاتی شما متناسب است یا خیر.
-
۲۵ ساعت
امنیت، پایش و بازیابی را در طراحی وارد کنید
برای طراحی خود، مرزهای اعتماد، احراز هویت، سطح دسترسی، اعتبارسنجی ورودی و نگهداری امن دادههای حساس را مشخص کنید. سپس لاگ، متریک، رهگیری درخواست (Tracing) و هشدارهای لازم را تعریف کنید. میتوانید متریکها را با Prometheus گردآوری، داشبوردها را با Grafana مشاهده و مسیر درخواست میان اجزا را با OpenTelemetry ثبت کنید. سناریوهایی مانند قطع سرویس وابسته، کندشدن پایگاه داده و شکست پردازش پسزمینه را بررسی کنید.
-
۳۰ ساعت
تصمیم معماری را مستند و قابل دفاع ارائه کنید
برای یک مسئله، چند گزینه طراحی بسازید و برای گزینه منتخب یک سند کوتاه تصمیم معماری بنویسید. در آن، مسئله، فرضها، گزینههای ردشده، پیامدها و معیارهای موفقیت را ثبت کنید. طراحی را برای همتیمی توضیح دهید و بر اساس پرسشهای او، ابهامهای نمودار و تصمیمها را اصلاح کنید.
زمان تقریبی یادگیری
برآورد مجموع زمان آموزش، مطالعه و تمرین تا رسیدن به سطح کاربردی؛ بسته به پیشزمینه شما میتواند کمتر یا بیشتر باشد.
پروژههای تمرینی
موارد زیر تصویری کلی از این بخش برای این مهارت ارائه میکنند.
-
طراحی سامانه رزرو نوبت
توضیح پروژه: برای سامانهای با پزشک، بیمار، تقویم، نوبت و پرداخت، مدل داده، API-های اصلی، وضعیتهای نوبت و سناریوی رزرو همزمان را طراحی کنید. مشخص کنید چگونه از رزرو تکراری یک بازه جلوگیری میشود.
-
معماری سامانه فروش بلیت رویداد
توضیح پروژه: جریان انتخاب صندلی، پرداخت، صدور بلیت و ارسال اعلان را طراحی کنید. برای لحظه شروع فروش، راهکار کنترل فشار درخواستها، صف انتظار و جلوگیری از فروش بیشازظرفیت را توضیح دهید.
-
طراحی سرویس کوتاهکننده نشانی
توضیح پروژه: رابط برنامهنویسی کاربردی (API) ساخت و هدایت نشانی کوتاه، مدل داده، کش مسیرهای پرتکرار، آمار بازدید و راهکار جلوگیری از سوءاستفاده را طراحی کنید. فرضهای ترافیکی خود را در سند ثبت کنید.
-
بازطراحی یک پروژه یکپارچه
توضیح پروژه: یک پروژه شخصی موجود را بررسی کنید و وابستگیهای آن را رسم کنید. خروجی باید شامل سند نیازمندی و فرضهای ظرفیت، نمودار اجزا و جریان درخواست، قرارداد API، مدل داده، جدول سناریوهای خطا و بازیابی و سند تصمیم معماری با گزینههای ردشده باشد. طراحی را با یک همتیمی بازبینی کنید. نبود فرض ظرفیت، مسئولیت مبهم اجزا، نداشتن راهکار خطا یا دلیل انتخابها یعنی پروژه هنوز کامل نیست.
پرسشهای رایج درباره طراحی سیستم و معماری نرمافزار
در این بخش، به تعدادی از پرسشهای رایج درباره این مهارت پاسخ داده شده است.
آیا طراحی سیستم فقط برای معمار نرمافزار لازم است؟
خیر. مهندس نرمافزار و توسعهدهنده بکاند هم برای طراحی یک قابلیت، API یا مدل داده به آن نیاز دارند. تفاوت اصلی در دامنه تصمیم و میزان مسئولیت است. معمار و سرپرست فنی معمولاً تصمیمهای بینتیمی و بلندمدتتری میگیرند.
برای یادگیری طراحی سیستم باید مایکروسرویس یاد بگیرم؟
خیر. مایکروسرویس فقط یک گزینه معماری است و برای بسیاری از محصولات کوچک یا تیمهای کمتجربه، سامانه یکپارچه ماژولار انتخاب سادهتر و کمهزینهتری است. ابتدا مرزبندی مسئولیتها و بدهبستانها را یاد بگیرید.
آیا بدون تجربه برنامهنویسی میتوان طراحی سیستم یاد گرفت؟
میتوانید مفاهیم پایه را بخوانید، اما قضاوت معماری بدون تجربه ساخت، خطایابی و تغییر یک پروژه واقعی سطحی میماند. بهتر است ابتدا برنامهنویسی، طراحی API و کار با پایگاه داده را در یک پروژه تمرین کنید.
در مصاحبه طراحی سیستم چه چیزی ارزیابی میشود؟
بسته به شرکت، سطح شغلی و نوع محصول، ممکن است شیوه روشنکردن نیازمندیها، مرزبندی اجزا، طراحی داده و API، تشخیص گلوگاه و توضیح بدهبستانها بررسی شود. پاسخ خود را با فرضهای مسئله، گزینههای ممکن و دلیل انتخابتان پیش ببرید. صرف نامبردن از ابزارها کافی نیست.
چگونه نمونهکار طراحی سیستم بسازم؟
برای چند مسئله مشخص، نمودار معماری، مدل داده، قراردادهای API، سناریوهای خطا و سند تصمیم معماری تهیه کنید. اگر امکان دارد، بخش کوچکی از طراحی را پیادهسازی و با لاگ یا متریک نشان دهید که طراحی شما قابل بررسی است.
تفاوت طراحی سیستم و معماری نرمافزار چیست؟
طراحی سیستم معمولا به حل یک مسئله مشخص با اجزا، داده و ظرفیت موردنیاز میپردازد. معماری نرمافزار نگاه پایدارتر به ساختار، مرزها و قواعد تکامل یک محصول دارد. در کار واقعی این دو حوزه همپوشانی زیادی دارند.
