معرفی
این نقشه راه برای توسعه‌دهنده یا مهندس نرم‌افزاری طراحی شده است که تجربه عملی توسعه دارد و می‌خواهد یاد بگیرد تصمیم‌های معماری را به نیاز محصول، محدودیت‌های فنی و پیامدهای عملیاتی متصل کند. هدف مسیر آموزش دوباره برنامه‌نویسی از صفر نیست. ابتدا تجربه موجود خود را ارزیابی می‌کنید و سپس از طراحی ماژولار و طراحی سیستم به داده، سیستم‌های توزیع‌شده، امنیت، عملکرد، عملیات و مستندسازی تصمیم‌های معماری می‌رسید. مسیر در هشت گام زیر پیش می‌رود:
ارزیابی تجربه توسعه
طراحی ماژولار
طراحی سیستم
طراحی داده و API
سیستم‌های توزیع‌شده
کیفیت‌های معماری
استقرار و مشاهده‌پذیری
مستندسازی و تکامل معماری
موارد مهم در مسیر یادگیری
در این مسیر، کیفیت‌های معماری (Quality Attributes) شامل موضوعاتی مانند Reliability، Security، Performance، Availability، Recoverability و قابلیت عملیات و نگهداری سامانه هستند. این ویژگی‌ها باید به سناریو و معیار قابل‌اندازه‌گیری تبدیل شوند و صرفاً با عباراتی مانند «سامانه سریع و مقیاس‌پذیر باشد» بیان نشوند.
جمع زمان گام‌های فعلی، حدود ۸۷۰ ساعت است. بازه ۷۰۰ تا ۱۰۰۰ ساعت در این صفحه برآورد آموزشی برای مطالعه و تمرین همین نقشه راه است و استانداردی برای رسیدن به عنوان Software Architect محسوب نمی‌شود. تجربه واقعی توسعه، انتشار، خطاهای تولید و تصمیم‌گیری تیمی ممکن است بسیار بیشتر از این زمان طول بکشد.
پروژه هر گام را روی سامانه‌ای قابل اجرا تمرین کنید. پروژه باید دست‌کم یک جریان اصلی کاربر، داده پایدار، API یا رابط ارتباطی، خطاهای قابل شبیه‌سازی و امکان تغییر تدریجی داشته باشد. خروجی هر مرحله را با یک توسعه‌دهنده باتجربه، Tech Lead یا منتور بررسی کنید و سؤال‌ها، مخالفت‌ها و اصلاحات را ثبت کنید. شواهد قابل ارائه شما می‌توانند شامل سند طراحی، نمودار معماری، قرارداد API، نتیجه تست، گزارش رخداد، ADR و برنامه مهاجرت باشند.
مخاطبان نقشه راه
این مسیر بیشتر برای توسعه‌دهندگان بک‌اند، فول‌استک و مهندسان نرم‌افزاری مناسب است که تجربه عملی توسعه و نگهداری نرم‌افزار دارند. تجربه Backend برای پروژه‌های این صفحه بسیار مفید است، اما پیش‌نیاز عمومی تمام نقش‌های معمار نرم‌افزار نیست. برای فردی که هنوز تجربه ساخت، انتشار و نگهداری یک نرم‌افزار واقعی ندارد، ابتدا مسیر توسعه نرم‌افزار مناسب‌تر است.
دستاورد پایانی
پس از تکمیل مسیر، می‌توانید نیازمندی‌های فنی و کیفیت‌های غیرعملکردی را به طراحی قابل‌اجرا تبدیل کنید، گزینه‌های معماری را مقایسه کنید، مرز اجزا و قراردادهای API را تعیین کنید، تصمیم‌ها را مستندسازی کنید و با داده‌های عملیاتی درباره بهبود تدریجی سامانه تصمیم بگیرید. این توانمندی شما را برای پذیرش مسئولیت‌های معماری در نقش‌های مهندس ارشد، سرپرست فنی یا معمار نرم‌افزار آماده می‌کند ولی عنوان شغلی نهایی به ساختار سازمان وابسته است.
پیش‌نیازها
موارد زیر پایه‌های لازم برای شروع را نشان می‌دهند.
- مهارت برنامه‌نویسی Programming
- مهارت برنامه‌نویسی شیءگرا Object-Oriented Programming
- مهارت توسعه بک‌اند Backend Development
- مهارت طراحی و توسعه API API Design and Development
- مهارت کنترل نسخه Version Control
- مهارت پایگاه داده و SQL Databases and SQL
- مهارت تست نرم‌افزار Software Testing
- مهارت اشکال‌زدایی نرم‌افزار Software Debugging
- تجربه توسعه و نگهداری حداقل یک نرم‌افزار واقعی، شخصی یا تیمی
- توانایی خواندن مستندات فنی انگلیسی
- آشنایی کاربردی با خط فرمان و محیط لینوکس
مسیر یادگیری شغل معمار نرم‌افزار
-
۱۰۰ ساعت
ارزیابی و تکمیل تجربه توسعه و نگهداری
هدف گام: توانایی‌های پایه خود را روی یک کدبیس واقعی ارزیابی کنید و شکاف‌های مشخص را پیش از ورود به مباحث معماری برطرف کنید.
این گام آموزش برنامه‌نویسی از صفر نیست. پیش‌نیازهای مسیر را با خواندن یک کدبیس موجود، دنبال‌کردن مسیر یک درخواست از ورودی تا ذخیره داده، اجرای تست‌ها و تحویل یک تغییر کوچک ارزیابی کنید.
اگر در یک بخش ضعف دارید، همان بخش را با تمرین تکمیلی رفع کنید. برای نمونه، توسعه‌دهنده‌ای با تجربه فرانت‌اند می‌تواند یک سرویس بک‌اند کوچک بسازد تا مسئولیت ذخیره‌سازی، خطا، احراز هویت و API را در عمل ببیند. خروجی این گام، فهرست کوتاهی از شکاف‌ها و شواهد رفع آن‌هاست.
مهارت‌ها
ابزارها
مفاهیم تکمیلی
ارزیابی پیش‌نیازهای توسعهخواندن و دنبال‌کردن جریان اجرای کدمدیریت خطا و ثبت رویدادهاتست رفتارهای حساسبازبینی تغییرات و تاریخچه کدبسته‌بندی محیط اجراپروژه پیشنهادی: یک سرویس مدیریت سفارش بسازید یا یک پروژه موجود را توسعه دهید. برای ایجاد سفارش، تغییر وضعیت و نمایش تاریخچه API بسازید، داده را در PostgreSQL نگهداری کنید، محیط اجرا را با Docker یکسان‌سازی کنید و برای سناریوهای خطا و تغییر وضعیت تست بنویسید.
معیار پایان گام: می‌توانید مسیر یک درخواست را در کد توضیح دهید، یک تغییر کوچک را همراه با تست تحویل دهید و برای هر شکاف پیش‌نیاز، تمرین تکمیلی و شواهد رفع آن را ثبت کنید.
-
۹۰ ساعت
طراحی ماژولار و مرزهای کد
هدف گام: یاد بگیرید مسئولیت‌های سامانه را به بخش‌هایی با مرز روشن تقسیم کنید تا تغییرات آینده هزینه کمتری داشته باشند.
معماری از مرزهای درست درون یک برنامه آغاز می‌شود، نه از شکستن زودهنگام برنامه به چند سرویس. دامنه مسئله را به بخش‌هایی با مسئولیت روشن تقسیم کنید و وابستگی‌های ناخواسته را شناسایی کنید.
برای هر ماژول مشخص کنید چه داده‌ای مالک آن است، چه قراردادی به دیگر بخش‌ها می‌دهد و چه چیزی نباید از بیرون دیده شود. سپس یک کدبیس درهم‌تنیده را به‌تدریج بازآرایی کنید. تصمیم مرزها و نتیجه بازبینی تغییرات را در Confluence ثبت کنید.
مهارت‌ها
ابزارها
مفاهیم تکمیلی
تفکیک مسئولیت‌هاوابستگی میان ماژول‌هاپنهان‌سازی جزئیات پیاده‌سازیمرزهای دامنه کسب‌وکاربازآرایی تدریجی کدثبت دلیل تغییرات ساختاریپروژه پیشنهادی: سرویس سفارش گام قبل را به ماژول‌های کاتالوگ، سفارش، پرداخت و اعلان تقسیم کنید. یک تغییر محصول فرضی، مانند افزودن کد تخفیف، را پیاده‌سازی کنید و در Confluence نشان دهید کدام ماژول‌ها باید تغییر کنند.
معیار پایان گام: برای هر ماژول، مسئولیت، داده‌های تحت مالکیت و قراردادهای بیرونی آن را می‌نویسید و می‌توانید دلیل مرزهای انتخاب‌شده را توضیح دهید.
-
۱۲۰ ساعت
طراحی سیستم بر پایه نیازمندی‌ها و Trade-offها
هدف گام: نیازهای محصول و Quality Attribute-ها را به اجزای سامانه، جریان داده و معیارهای قابل سنجش تبدیل کنید.
طراحی سیستم (System Design) با پرسش آغاز می‌شود: چه کسانی از سامانه استفاده می‌کنند، کدام جریان‌ها حساس‌اند، چه حجم یا رشد احتمالی داریم و خطا چه هزینه‌ای دارد؟ پیش از انتخاب فناوری، فرض‌ها و کیفیت‌های غیرعملکردی را بنویسید.
چند گزینه طراحی برای یک مسئله بسازید و هرکدام را با هزینه توسعه، پیچیدگی عملیات، قابلیت تغییر، عملکرد و ریسک مقایسه کنید. برای ترسیم جریان‌ها و بازبینی گروهی طرح از Miro استفاده کنید. هدف ابزار، ثبت پرسش‌ها و اصلاح طراحی در جلسه بازبینی است، نه تولید نمودار تزئینی.
مهارت‌ها
ابزارها
مفاهیم تکمیلی
تبدیل نیاز محصول به سناریوی فنیکیفیت‌های غیرعملکردیبرآورد بار و ظرفیت با فرض‌های شفافطراحی جریان درخواست و دادهتحلیل مصالحه میان هزینه و پیچیدگیانتخاب معماری یکپارچه یا سرویس‌گرامعیار پذیرش طراحیپروژه پیشنهادی: برای یک سامانه رزرو آنلاین، سند طراحی تهیه کنید: سناریوهای اصلی، اجزا، جریان داده، فرض‌های بار، نقاط شکست و دو گزینه معماری را بنویسید. نمودار را در Miro با یک هم‌تیمی بازبینی کنید، پرسش‌های مطرح‌شده را ثبت کنید و یک گزینه را با دلایل و پیامدهایش انتخاب کنید.
معیار پایان گام: می‌توانید برای یک مسئله مبهم، پرسش‌های روشن‌کننده مطرح کنید، نمودار سطح‌بالای سامانه بکشید و دست‌کم دو گزینه را با مصالحه‌های مشخص مقایسه کنید.
-
۱۱۰ ساعت
طراحی داده و قراردادهای ارتباطی
هدف گام: برای مالکیت داده، سازگاری اطلاعات و ارتباط قابل‌تغییر میان اجزای سامانه تصمیم بگیرید.
بسیاری از شکست‌های معماری از مرز داده و قراردادهای مبهم API می‌آیند. مدل داده را از نیازهای دامنه استخراج کنید، الگوهای خواندن و نوشتن را بشناسید و برای تغییر طرح داده، مهاجرت قابل‌بازگشت در نظر بگیرید.
قرارداد API باید نسخه‌پذیر، قابل‌آزمون و دارای رفتار خطای روشن باشد. Postman را برای اجرای مجموعه آزمون قرارداد به کار ببرید. Apache Kafka فقط برای تمرین یک ارتباط ناهمگام انتخاب شده است. رویداد را منتشر کنید، مصرف‌کننده را متوقف و دوباره فعال کنید و رفتار تحویل تکراری را ثبت کنید.
مهارت‌ها
ابزارها
مفاهیم تکمیلی
مالکیت و مرز دادهمدل‌سازی موجودیت‌ها و روابطمهاجرت و سازگاری طرح دادهنسخه‌بندی قرارداد APIطراحی خطاهای قابل‌فهمارتباط همگام و ناهمگامتحویل تکراری و هم‌توانی عملیاتسازگاری نهایی دادهپروژه پیشنهادی: برای سامانه رزرو، قراردادهای API و مدل داده طراحی کنید. مجموعه آزمون قرارداد را در Postman اجرا کنید. سپس رویداد «تأیید رزرو» را با Apache Kafka منتشر کنید و نشان دهید سرویس اعلان پس از دریافت دوباره یک پیام، اعلان تکراری نمی‌فرستد.
معیار پایان گام: می‌توانید مالک هر داده را تعیین کنید، تغییر ناسازگار API را تشخیص دهید و برای خطا، تکرار پیام یا شکست یکپارچه‌سازی راهکار مشخص پیشنهاد دهید.
-
۱۳۰ ساعت
درک سیستم‌های توزیع‌شده و تاب‌آوری
هدف گام: رفتار سامانه را در شرایط تأخیر، قطعی شبکه، شکست سرویس و پردازش هم‌زمان تحلیل کنید.
در سامانه توزیع‌شده، تماس شبکه مانند فراخوانی یک تابع محلی قابل‌اعتماد نیست. زمان‌پایان، تلاش مجدد، ازدحام، داده تکراری و شکست جزئی را در طراحی در نظر بگیرید. هدف این گام حفظ سرویس در همه شرایط نیست و هدف، تعریف رفتار قابل‌قبول در زمان خطاست.
Apache JMeter را برای تولید بار و آشکارکردن اثر تأخیر وابستگی به کار ببرید. Redis را فقط در یک سناریوی مشخص، مانند نگهداری موقت نتیجه هم‌توانی عملیات یا کش داده پرتکرار، آزمایش کنید و اثر آن بر سازگاری داده را توضیح دهید.
مهارت‌ها
سیستم‌های توزیع‌شدهشبکه و ارتباطات سرویس‌هاپایش و مشاهده‌پذیری سامانه‌هاپشتیبان‌گیری و بازیابی پس از بحرانابزارها
مفاهیم تکمیلی
شکست جزئی در شبکهزمان‌پایان و تلاش مجددکنترل ازدحام و محدودسازی نرخالگوهای قطع‌کننده مدارهم‌توانی عملیاتجبران تراکنش‌های توزیع‌شدهکش و ناسازگاری دادهطراحی سناریوی بازیابیپروژه پیشنهادی: نسخه چندسرویسی سامانه رزرو را در محیط Docker اجرا کنید. با Apache JMeter پاسخ سرویس پرداخت را کند کنید و با قطع موقت آن، رفتار سیستم را آزمایش کنید. برای جلوگیری از ثبت رزرو تکراری، یک کلید هم‌توانی در Redis پیاده‌سازی یا طراحی آن را مستند کنید.
معیار پایان گام: می‌توانید دست‌کم سه حالت شکست جزئی را شبیه‌سازی کنید، پیامد آن‌ها را توضیح دهید و برای هرکدام رفتار مورد انتظار سامانه و راهکار کاهش ریسک بنویسید.
-
۱۱۰ ساعت
طراحی امنیت، کارایی و پایداری
هدف گام: کیفیت‌های غیرعملکردی را از شعار به الزام‌های طراحی و معیارهای آزمون تبدیل کنید.
امنیت، کارایی و دسترس‌پذیری ویژگی‌هایی نیستند که پس از تکمیل توسعه اضافه شوند. برای جریان‌های حساس، تهدیدها، سطح دسترسی، داده‌های محرمانه و نقاط ورودی را مشخص کنید. هم‌زمان، گلوگاه‌های محتمل مانند پرس‌وجوی پرهزینه، اتصال‌های محدود و وابستگی‌های کند را بررسی کنید.
معمار نباید صرفاً بگوید سامانه «مقیاس‌پذیر» یا «امن» است. باید مشخص کند کدام سناریو اندازه‌گیری می‌شود، چه سطحی از افت سرویس پذیرفتنی است و کدام کنترل امنیتی مسئولیت کدام بخش است. نتیجه این گام، فهرست اولویت‌دار ریسک‌ها و آزمون‌هاست.
مهارت‌ها
ابزارها
مفاهیم تکمیلی
مدل‌سازی تهدیدمرزبندی اعتماد در سامانهاحراز هویت و کنترل دسترسیمدیریت داده‌های حساستعریف هدف سطح خدمتشناسایی گلوگاه عملکردآزمون بار و تحلیل نتایجاولویت‌بندی ریسک‌های فنیپروژه پیشنهادی: برای سامانه رزرو، یک مدل تهدید ساده و برنامه آزمون کارایی بنویسید. یک سناریوی بار را با Apache JMeter اجرا کنید، پرس‌وجوی گلوگاه را در PostgreSQL بررسی کنید و یک تصمیم معماری یا اصلاح فنی را با اثر و ریسک آن پیشنهاد کنید.
معیار پایان گام: می‌توانید یک جریان حساس را از نظر تهدید و عملکرد تحلیل کنید، معیار قابل‌اندازه‌گیری تعریف کنید و یافته‌ها را به اقدام فنی اولویت‌دار تبدیل کنید.
-
۱۰۰ ساعت
استقرار، مشاهده‌پذیری و یادگیری از تولید
هدف گام: طراحی معماری را به رفتار واقعی سامانه در محیط عملیاتی متصل کنید.
مشاهده‌پذیری (Observability) یعنی بتوانید از خروجی‌های سامانه، وضعیت درونی و علت مسئله را بررسی کنید. لاگ‌ها، متریک‌ها و ردیابی توزیع‌شده (Distributed Tracing) را طوری طراحی کنید که بتوانند به پرسش‌های عملیاتی پاسخ دهند: خطا کجا رخ داده است، کدام وابستگی کند شده و چه تغییری بر کاربران اثر گذاشته است.
Prometheus برای جمع‌آوری متریک، Grafana برای ساخت داشبورد و OpenTelemetry برای ارسال داده ردیابی این تمرین استفاده می‌شوند. Kubernetes و Terraform وابسته به محیط کار هستند. فقط اگر پروژه شما به ارکستراسیون کانتینر یا مدیریت زیرساخت تکرارپذیر نیاز دارد، آن‌ها را به تمرین اضافه کنید. در غیر این صورت، نیازهای استقرار و مرز مسئولیت توسعه و عملیات را مستند کنید.
مهارت‌ها
کانتینرسازی نرم‌افزاریکپارچه‌سازی و تحویل مستمرپایش و مشاهده‌پذیری سامانه‌هامدیریت زیرساخت به‌عنوان کدمدیریت زیرساخت ابریارتباطات فنیابزارها
مفاهیم تکمیلی
طراحی لاگ‌های قابل‌جست‌وجومتریک‌های سرویس و کسب‌وکارردیابی یک درخواست میان سرویس‌هاهشداردهی مبتنی بر اثر کاربراستقرار تدریجی و بازگشت نسخهمدیریت پیکربندی و رازهامرز مسئولیت توسعه و عملیاتتحلیل رخداد پس از رفع مشکلپروژه پیشنهادی: سامانه پروژه را با Docker اجرا کنید و با GitLab یک فرایند ساده تحویل مستمر بسازید. با OpenTelemetry یک جریان رزرو را ردیابی کنید، متریک‌های خطا و تأخیر را با Prometheus جمع‌آوری کنید و در Grafana داشبورد بسازید. سپس یک رخداد ساختگی را تحلیل و گزارش پس از رخداد تهیه کنید.
معیار پایان گام: می‌توانید با استفاده از لاگ، متریک و ردیابی توزیع‌شده یک مسئله عملیاتی را تحلیل کنید و برای جلوگیری از تکرار آن، اقدام معماری یا عملیاتی مشخص پیشنهاد دهید.
-
۱۱۰ ساعت
مستندسازی تصمیم و هدایت تکامل معماری
هدف گام: طراحی‌های قابل‌بحث و قابل‌اجرا تولید کنید و تغییر معماری را به‌صورت تدریجی هدایت کنید.
معمار نرم‌افزار باید تصمیم را قابل‌فهم، قابل‌اعتراض و قابل‌بازبینی کند. برای تصمیم‌های مهم، زمینه مسئله، گزینه‌های بررسی‌شده، انتخاب، پیامدها و تاریخ بازبینی را ثبت کنید. نمودارها باید پاسخ‌گوی پرسش مخاطب باشند، نه صرفاً زیبا یا پیچیده.
روی یک سامانه موجود، برنامه تکامل معماری بنویسید. بدهی فنی را به فهرست آرزوها تبدیل نکنید؛ آن را به ریسک، هزینه تغییر، رخدادهای واقعی یا محدودیت تحویل متصل کنید. Miro را برای جلسه بازبینی و Confluence را برای ثبت تصمیم‌ها به کار ببرید؛ بازخوردهای جلسه باید به اصلاح مشخص در طرح یا برنامه مهاجرت منتهی شود.
مهارت‌ها
ارتباطات فنیرهبری فنی تیم نرم‌افزارمدیریت ذی‌نفعانبرنامه‌ریزی تحویل فنی نرم‌افزارمنتورینگ فنی توسعه‌دهندگان نرم‌افزارتسهیل‌گری تیمابزارها
مفاهیم تکمیلی
ثبت تصمیم معمارینمودار زمینه، کانتینر و مؤلفهبیان فرض‌ها و محدودیت‌هابازبینی طراحی با تیم‌های مختلفاولویت‌بندی بدهی فنی با شواهدمهاجرت تدریجی و سازگاری نسخه‌هامعیار موفقیت و برنامه بازگشتتسهیل توافق بر تصمیم فنیپروژه پیشنهادی: برای پروژه رزرو، یک بسته معماری آماده کنید: نمودارهای اصلی، حداقل ۳ تصمیم معماری مستند در Confluence، فهرست ریسک‌ها، برنامه مهاجرت یک بخش پرریسک و گزارش کوتاه بازبینی طرح در Miro. از داده ردیابی OpenTelemetry برای توجیه اولویت یک ریسک عملیاتی استفاده کنید.
معیار پایان گام: می‌توانید یک تصمیم معماری را با زمینه، گزینه‌ها و پیامدها مستند کنید، به پرسش‌های فنی و غیرفنی پاسخ دهید و یک مهاجرت تدریجی با معیار سنجش طراحی کنید.
زمان تقریبی یادگیری
برآورد مجموع زمان آموزش، مطالعه و تمرین تا رسیدن به سطح کاربردی؛ بسته به پیش‌زمینه شما می‌تواند کمتر یا بیشتر باشد.
ابزارهای مسیر
موارد زیر تصویری کلی از این بخش برای این مسیر ارائه می‌کنند.
خطاهای رایج مسیر
برای آشنایی بهتر با این مسیر، توجه به موارد زیر می‌تواند مفید باشد.
-
انتخاب مایکروسرویس پیش از شناخت مسئله
ابتدا مرزهای دامنه، تعداد تیم‌ها، الگوی تغییر و نیاز عملیاتی را بررسی کنید. اگر یک برنامه یکپارچه نیاز را با پیچیدگی کمتر پاسخ می‌دهد، همان را انتخاب و مسیر تغییر آینده را مستند کنید.
-
یادگیری الگوها بدون تمرین مصالحه
برای هر الگو، یک مسئله واقعی، هزینه پیاده‌سازی، اثر عملیاتی و حالت شکست بنویسید. هرگز الگو را بدون توضیح مسئله‌ای که حل می‌کند پیشنهاد ندهید.
-
تمرکز بر نمودار و نادیده‌گرفتن کد و تولید
هر طراحی را با نمونه اولیه، تست، لاگ یا سناریوی خطا اعتبارسنجی کنید. معماری باید به کد، استقرار و رفتار قابل‌مشاهده سامانه وصل باشد.
-
فرض‌کردن نیازهای غیرعملکردی
به‌جای واژه‌هایی مانند «سریع» یا «مقیاس‌پذیر»، سناریو، معیار سنجش و سطح قابل‌قبول خدمت را با محصول و عملیات روشن کنید.
-
وابستگی مستقیم میان سرویس‌ها و داده‌ها
مالکیت داده و قراردادهای ارتباطی را صریح کنید. دسترسی مستقیم یک سرویس به داده سرویس دیگر را فقط با دلیل روشن و پیامدهای پذیرفته‌شده انجام دهید.
-
نادیده گرفتن هزینه عملیات ابزارهای جدید
پیش از افزودن صف پیام، کلاستر یا ابزار مشاهده‌پذیری، مسئول نگهداری، مهارت تیم، هزینه رخداد و برنامه پشتیبانی آن را مشخص کنید.
-
ثبت نکردن دلیل تصمیم‌های معماری
برای تصمیم‌های مهم، زمینه، گزینه‌های ردشده، انتخاب و پیامدها را کوتاه و تاریخ‌دار ثبت کنید. سند را پس از رخداد یا تغییر نیاز بازبینی کنید.
-
تبدیل بدهی فنی به فهرست مبهم
هر مورد بدهی را به ریسک مشخص، هزینه تغییر، خطای رخ‌داده یا معیار عملکرد وصل کنید و برای آن اولویت و گام مهاجرت تعیین کنید.
چک‌لیست آمادگی شغلی
پیش از ادامه، فهرست زیر را مرور کنید و مطمئن شوید همه موارد را پوشش داده‌اید:
- می‌توانم نیازهای محصول و کیفیت‌های غیرعملکردی را به سناریوهای فنی قابل‌سنجش تبدیل کنم.
- می‌توانم برای یک سامانه، اجزا، مرزهای مسئولیت، جریان داده و قراردادهای اصلی را طراحی کنم.
- می‌توانم معماری یکپارچه و سرویس‌گرا را با توجه به هزینه، تیم و ریسک مقایسه کنم.
- می‌توانم مالکیت داده، تغییر طرح داده و نسخه‌بندی API را برای یک سامانه توضیح دهم.
- می‌توانم شکست جزئی، تأخیر شبکه و پردازش تکراری پیام را در طراحی تحلیل کنم.
- می‌توانم برای یک جریان حساس، تهدیدها، کنترل‌های امنیتی و معیارهای کارایی را مشخص کنم.
- می‌توانم با لاگ، متریک و ردیابی توزیع‌شده یک مسئله عملیاتی را تحلیل کنم.
- می‌توانم تصمیم معماری را با گزینه‌ها، مصالحه‌ها، پیامدها و زمان بازبینی مستند کنم.
- می‌توانم برنامه مهاجرت تدریجی یک بخش پرریسک را همراه با معیار موفقیت و بازگشت طراحی کنم.
پرسش‌های پرتکرار
در این بخش، به تعدادی از پرسش‌های رایج درباره این مسیر پاسخ داده شده است.
برای تمرین معماری، چه پروژه‌ای انتخاب کنم؟
پروژه‌ای انتخاب کنید که فقط یک رابط کاربری نمایشی نباشد. باید یک جریان اصلی کاربر، داده پایدار، API، خطاهای قابل‌شبیه‌سازی و چند تغییر محتمل محصول داشته باشد. سامانه رزرو، سفارش یا مدیریت نوبت مناسب‌اند، زیرا می‌توانید برای آن‌ها مالکیت داده، تأخیر وابستگی و مهاجرت تدریجی را تمرین کنید.
چگونه مطمئن شوم طراحی من فقط یک نمودار زیبا نیست؟
طراحی را با یک سناریوی تغییر محصول، یک آزمون خطا و یک بازبینی با هم‌تیمی امتحان کنید. اگر بتوانید مشخص کنید چه بخشی تغییر می‌کند، چه چیزی ممکن است بشکند، چگونه آن را می‌سنجید و چرا گزینه دیگری را رد کرده‌اید، طراحی شما شواهد عملی دارد.
برای تکمیل این مسیر چقدر زمان لازم است؟
با پیش‌نیازهای ذکرشده، بسته به پیش‌زمینه و زمان هفتگی، حدود ۷۰۰ تا ۱٬۰۰۰ ساعت تمرین و مطالعه هدفمند لازم است. تجربه واقعی انتشار، رخداد و تغییر نیاز محصول معمولاً زمان بیشتری از ساعت‌های آموزشی می‌خواهد.
آیا یادگیری Kubernetes برای معمار نرم‌افزار ضروری است؟
خیر. باید اثر Kubernetes بر استقرار، مقیاس‌پذیری و عملیات را بفهمید، اما عمق یادگیری به محیط کاری بستگی دارد. اگر تیم از Kubernetes استفاده نمی‌کند یا تیم دواپس مسئول اجراست، مستندسازی نیازهای استقرار و مصالحه‌ها از راه‌اندازی کلاستر مهم‌تر است.
آیا Apache Kafka، Prometheus و Terraform را باید در همه پروژه‌ها استفاده کنم؟
خیر. Kafka برای تمرین ارتباط ناهمگام، Prometheus و Grafana برای تمرین مشاهده‌پذیری و Terraform برای زیرساخت تکرارپذیر کاربرد دارند. فقط زمانی آن‌ها را انتخاب کنید که مسئله پروژه به پیام ناهمگام، سنجش رفتار عملیاتی یا مدیریت زیرساخت نیاز دارد. در غیر این صورت، دلیل انتخاب نکردن آن‌ها را مستند کنید.
آیا باید همه الگوهای معماری را حفظ کنم؟
خیر. نام الگو به‌تنهایی ارزش ندارد. مهم این است که مسئله، محدودیت‌ها، پیامدها و شرایط نامناسب‌بودن هر راهکار را تشخیص دهید و انتخاب خود را با شواهد توضیح دهید.
پروژه‌های این نقشه راه برای نشان‌دادن توان معماری کافی هستند؟
پروژه‌ها برای تمرین و ساخت شواهد اولیه مناسب‌اند، اما جای تجربه تیمی و عملیاتی را کامل نمی‌گیرند. برای ارائه توان خود، بسته تصمیم‌های مستند، نتیجه بازبینی طراحی، سناریوی شکست و گزارش اصلاح سامانه را کنار کد پروژه منتشر کنید.
