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

معماری نرم‌افزار در گذر زمان

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

محورهای اصلی
معماری تکاملی Evolutionary Architecture
معماری مستمر Continuous Architecture
شروع دوره فعال
۱ شهریور ۱۴۰۵
۲۰
جلسه
۶۰
ساعت محتوا
روزهای برگزاری یکشنبه‌ها
ساعت کلاس ۱۸:۰۰ تا ۲۱:۰۰ — به وقت تهران
نحوه برگزاری آنلاین
شهریه دوره ۱۰،۰۰۰،۰۰۰ تومان
ثبت‌نام

معماری نرم‌افزار در گذر زمان

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

01

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

02

چرا انحراف‌های کوچک به‌مرور عادی می‌شوند، و چگونه می‌توان آن‌ها را قبل از دیر شدن دید؟

03

چگونه می‌توان تشخیص داد یک تصمیم معماری هنوز یک نیاز واقعی است، یا فقط از گذشته به‌جا مانده است؟

04

چگونه می‌توان یک تغییر بزرگ را به گام‌های کوچک، قابل‌سنجش و برگشت‌پذیر تبدیل کرد؟

این دوره چه مباحثی را پوشش می‌دهد؟

۱. سیستم‌ها چگونه تغییر می‌کنند؟

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

آنچه تفکر سیستمی درباره‌ی تغییر و دینامیک آن به ما می‌آموزد.
  • چرا انتظارهای ما از سیستم، اغلب اشتباه از کار درمی‌آیند؟ (تفکر خطی-غیرخطی)
  • چطور تصمیم‌های کوچک به مرور روی هم انباشته می‌شوند و باعث پیچیدگی می‌شوند؟ (جریان و انباشت)
  • فاصله‌ی میان تصمیم‌ها و پیامدهایشان چه تأثیری بر ما دارد؟ (حلقه‌های بازخورد و تاخیر)
  • چرا گاهی یک تغییر کوچک، همه‌چیز را دگرگون می‌کند؟ (آستانه‌ها، نقاط عطف، وابستگی مسیر و ...)
  • کدام تغییر، بیشترین اثر را بر رفتار یک سیستم دارد؟ (اهرم، نقاط اهرمی و مقاومت در برابر تغییر)
  • چگونه پدیده‌هایی در سیستم ظهور می‌کنند که در هیچ‌یک از اجزای آن وجود ندارد؟ (Emergence)
نرم‌افزار چگونه در گذر زمان تغییر می‌کند؟
  • الگوها و سازوکارهای حاکم بر رشد، تغییر و تکامل نرم‌افزار در گذر زمان
  • چگونه نقص‌ها و مشکلات، به‌مرور به جزئی جدایی‌ناپذیر از سیستم تبدیل می‌شوند؟
  • چگونه میان‌برهای امروز، هزینه‌ی تصمیم‌های بعدی را افزایش می‌دهند؟
  • چگونه وابستگی‌های کوچک، به‌مرور کل اجزای سیستم را به هم گره می‌زنند؟
  • چگونه یک ساختار معیوب، میان‌برها را تشویق می‌کند و کار درست را سخت‌تر می‌کند؟
۲. انسجام در طول زمان

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

تناسب، انسجام و یکپارچگی (Fitness, Coherence & Integrity)
  • چه چیزی معیار درستی و تناسب یک طراحی را مشکل می‌کند؟ (Context و محدودیت‌های معنادار)
  • چرا تناسب (Fitness) را نمی‌توان در هیچ جزئی به‌تنهایی دید؟
  • انسجام در دل تعارض‌ها: چگونه یک سیستم می‌تواند به محدودیت‌های متضاد پاسخ دهد و همزمان منسجم (Coherent) باقی بماند؟
Fitness Functions
  • Fitness Function چیست و چه مشکلی را حل می‌کند؟
  • چه چیزی یک Fitness Function را از یک Test یا Metric معمولی متمایز می‌کند؟
  • چه معیارهایی یک Fitness Function را موثر می‌کنند؟
درک نقص‌های طراحی - Design Flaws
  • چه زمانی یک شکاف یا تعارض، به تهدیدی برای انسجام سیستم تبدیل می‌شود؟
  • چرا رفع یک نقص و مشکل بدون فهم ریشه آن، اغلب به بروز مشکلات جدید می‌انجامد؟
  • چطور یک تیم می‌تواند سال‌ها با یک مشکل درگیر باشد بدون اینکه متوجه آن باشد؟
  • نقص‌ها چطور تغییر و تکامل پیدا می‌کنند و چه عواملی بر مسیر آنها تاثیر می‌گذارد؟
  • نقص‌ها و کمبود‌‌ها چگونه در طول زمان تغییر پیدا می‌کنند و به مسائل جدیدی تبدیل می‌شوند؟
۳. تغییر و تکامل مستمر
تمرکز اصلی دوره

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

تکامل‌پذیری - Evolvability
  • Evolvability به عنوان یک Meta-Characteristic
  • نگه‌داری آسان الزاما به معنای تکامل‌پذیری بیشتر نیست (maintainability vs evolvability)
  • داشتن گزینه‌های بیشتر لزوما به معنای تکامل راحت‌تر نیست. (flexibility vs evolvability)
  • از معماری مبتنی بر پیش‌بینی، به معماری مبتنی بر تکامل
  • تغییر تدریجی کوچک و هدایت‌شده (Guided, Incremental Change)
گام‌های کوچک، هدفمند و کنترل‌شده
  • اصلاحات مستمر تدریجی یا بازنویسی‌های بزرگ؟ پیامدهای هر انتخاب
  • شکستن تغییرات بزرگ ساختاری به مجموعه‌ای از اقدامات ساده و قابل انجام
  • ابتدا تغییر را آسان کن، سپس تغییر آسان را اعمال کن (Preparatory Refactoring)
  • مهاجرت تدریجی از وابستگی‌ها بدون اختلال در کارکرد
  • آخرین زمان برای تعویق تصمیم (Last Responsible Moment)
برگشت‌پذیری و کنترل دامنه تاثیر
  • محدود کردن انتشار تغییرات یک بخش به سایر بخش‌ها (Seam، Anti-Corruption Layer و ...)
  • اجرای هم‌زمان راهکار قدیمی و جدید در دوران گذار (Strangler Fig، Branch by Abstraction و ...)
  • مکانیزم‌های استقرار برای افزایش برگشت‌پذیری و کنترل‌پذیری (Feature Flags، Dark Launching و ...)
  • مسئله برگشت‌پذیری (Reversibility)
Safety Net - تست، نظارت و حفظ تعهدات
  • طراحی Test Suite با هدف پشتیبانی از تغییرات مستمر
  • طراحی برای Observability و سنجش مستمر تاثیر تغییرات
  • تغییر در Contract‌ها با حفظ تعهدات (Backward Compatibility، API Versioning و ...)
بلوغ فرهنگ مهندسی
  • معماری پیوسته، نیازمند یک چرخه‌ی توسعه‌ی پیوسته است (integration, testing, delivery, deployment و ...)
  • Practiceهای مهندسی که تغییر مستمر را ممکن می‌کنند (branching strategy, pipeline maturity, small frequent deployments و ...)
  • بهبود تدریجی و پیوسته‌ی کد در جریان توسعه‌ی روزمره (Opportunistic Refactoring، Boy Scout Rule، ...)
  • فرهنگ آزمایش مستمر - Continuous Experimentation Culture
  • فرهنگ بهبود مستمر - Continuous Improvement Culture
  • تیمی که از اشتباه می‌ترسد، نمی‌تواند تغییر کند - مبحث امنیت روانی Psychological Safety
۴. تشخیص انحراف

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

آنچه پنهان می‌ماند
  • حلقه‌های بازخورد پنهان: مشکلاتی که زمینه‌ی تداوم و تشدید خود را فراهم می‌کنند
  • فاصله‌ی میان تصویر ذهنی تیم از سیستم و وضعیت واقعی آن
  • عوامل سیاسی-اجتماعی سازمان که بی‌صدا معماری سیستم را جهت می‌دهند
  • وابستگی‌های مخفی (temporal coupling، shared context، implicit contracts و ...)
  • فرضیه‌های دیروز که در ساختار امروز پنهان مانده‌اند
  • چرا تیم‌هایی که داخل drift هستند، آن را نمی‌بینند؟
سیگنال‌ها و نشانه‌ها
  • Structural Code Analysis: تحلیل ساختاری کد
  • Behavioral Code Analysis: تحلیل کد از طریق بررسی الگوی تغییراتش در طول زمان
  • سیگنال‌های عملیات (Deployment Frequency، Change Failure Rate و ...)
  • تاثیر معماری بر سیگنال‌های Delivery
  • سیگنال‌های تیمی (وابستگی به افراد، قهرمان‌پروری و ...)
  • سیگنال‌های شناختی (Cognitive Load، Onboarding Time و ...)
  • بررسی روند Fitness Function‌ها در طول زمان
ارزیابی و بازبینی مستمر
  • بازبینی مستمر معماری به عنوان بخشی از چرخه‌ی روزمره توسعه
  • مرئی کردن وضعیت معماری برای کل تیم (Architecture Visibility)
  • ساخت و نگهداری درک مشترک از معماری در کل تیم
۵. معماری از منظر کسب‌وکار

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

سرمایه‌گذاری معماری در طول زمان
  • هدایت سرمایه‌گذاری‌های معماری و بازنگری آن‌ها در طول زمان
  • عوامل تاثیرگذار بر تصمیمات سرمایه‌گذاری معماری (مزیت رقابتی، مدل کسب‌وکار، بلوغ محصول و ...)
  • الگوهای تکامل متفاوت در حوزه‌های مختلف سیستم (مزیت رقابتی، بلوغ فناوری و ...)
  • ابزارهای Mapping تکامل حوزه‌های سیستم (Wardley Mapping و ...)
ساخت زبان مشترک با ذی‌نفع‌ها
  • شکاف میان ارزش معماری و درک ذی‌نفع‌ها از آن
  • از چه زمانی سرمایه‌گذاری روی معماری شروع به جبران هزینه خود می‌کند؟ (Design Payoff Line)
  • استعاره «بدهی فنی»: چه چیزی می‌گوید و چه چیزی را پنهان می‌کند؟
۶. پویایی انسانی معماری

سیستم‌ها بازتابی از انسان‌هایی هستند که آن‌ها را می‌سازند و انسان‌ها هرگز ثابت نمی‌مانند. تیم‌ها شکل می‌گیرند و از هم می‌پاشند، مالکیت جابه‌جا می‌شود، و کسانی که دلیلِ اصلیِ شکل‌گیری یک طراحی را می‌دانستند، در نهایت می‌روند و آن فهم را با خود می‌برند. سیستم، تیم‌ها و انسان‌ها هرکدام مسیر تکامل خود را با سرعت و دینامیک متفاوتی طی می‌کنند. اصطکاکی که از این ناهماهنگی به وجود می‌آید، همراه با تغییر مسئولیت‌ها و محو شدن نیت‌های اولیه، به اندازه هر عامل فنی دیگری، بر معماری سیستم اثر می‌گذارد. این بخش از دوره درباره‌ی همین نیروی انسانی در معماری است: اینکه چگونه ساختار سیستم و ساختار سازمانِ آن، در طول زمان پیوسته روی یکدیگر تأثیر می‌گذارند و یکدیگر را بازتعریف می‌کنند.

سازمان و معماری، آینه‌ی یکدیگر
  • چگونه ساختار ارتباطی تیم‌ها در ساختار سیستم بازتاب پیدا می‌کند؟ (Conway's Law)
  • تفاوت سرعت تغییر سیستم و سرعت تغییر کسب‌وکار به عنوان یکی از دلایل دائمی ناهماهنگی
  • مداخله آگاهانه‌ و مستمر در ساختار تیم‌ها با هدف رسیدن به معماری موردنظر (Inverse Conway Maneuver)
  • بازبینی مستمر مرزها برای حفظ ظرفیت ذهنی تیم‌ها (Cognitive Load)
از دست رفتن دانش معماری
  • عدم وجود ADR و محو شدن نیت‌های اولیه‌
  • اسطوره‌ها: باورهای جا افتاده‌ای درباره‌ی سیستم که با گذشت زمان جای تحلیل واقعی را می‌گیرند
  • از دست رفتن توانایی اعتبارسنجی تصمیمات جدید با رفتن افراد کلیدی
  • مالکیت مشترک معماری - توزیع دانش و مسئولیت در کل تیم
راهبری معماری: از تصمیم تا بازخورد
  • تکامل فرآیند تصمیم‌گیری معماری با رشد و بلوغ تیم
  • از معمار به عنوان تصمیم‌گیرنده تا معمار به عنوان توانمندساز
  • توزیع اختیار تصمیم‌گیری بدون از دست دادن انسجام معماری
  • اقتصاد توجه: چه چیزی توجه ما را جلب می‌کند و ما توجه دیگران را به چه سمتی هدایت می‌کنیم؟

نسبت این دوره با AI و تغییرات نوظهور این حوزه

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

پرسش اصلی ما این است: مباحثی که در این دوره دنبال می‌کنیم، با تحولات AI چگونه تحت‌تاثیر قرار میگیرند؟

برای مثال، نمونه‌ای از این پرسش‌ها:
؟

وقتی تولید کد ارزان می‌شود، مرز میان «بازنویسی» و «تکامل تدریجی» کجا جابه‌جا می‌شود؟

؟

وقتی بخش بزرگی از کد را coding agentها می‌نویسند، فهم مشترک از سیستم چه سرنوشتی پیدا می‌کند؟

؟

وقتی کد با سرعتی چند برابر رشد می‌کند، انحراف معماری را چطور می‌توان به‌موقع دید؟

…

و پرسش‌هایی از این دست

همچنین، مدیریت دانش و کار عملی دوره را با کمک AI پیش می‌بریم

مدیریت دانش دوره

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

کارگاه عملی با coding agentها

در دوره‌های قبلی، برای جلو بردن زمان و نشان دادن مراحل مختلفِ تغییر یک سیستم، از branchهای جدا برای هر مرحله استفاده می‌کردیم. این بار، حداقل بخشی از این مراحل را با coding agentها پیش می‌بریم تا ببینیم هر تغییر واقعا در عمل چطور اتفاق می‌افتد و به چه ملاحظاتی نیاز دارد.

مخاطبین دوره

این دوره برای چه کسانی مناسب است؟

  • ✓ معماران نرم‌افزاری که با اصول طراحی سیستم‌ها آشنا هستند، اما نمی‌توانند آن را در طول زمان زنده و منسجم نگه دارند
  • ✓ راهبران فنی و مهندسان ارشد (Tech Lead، Principal Engineer و نقش‌های مشابه) که هر روز انحراف تدریجی معماری سیستم را حس می‌کنند، اما چارچوبی برای درک آن و اقدام برای اصلاح مسیر ندارند
  • ✓ مدیران فنی (Engineering Manager، CTO و نقش‌های مشابه) که می‌خواهند فرآیند تصمیم‌گیری معماری و اجرای آن، هم‌زمان با رشد تیم و سیستم، مقیاس‌پذیر باقی بماند
  • ✓ افرادی که دوره‌های قبلی مسیر معماری را گذرانده‌اند و دنبال گام بعدی در این مسیر هستند
پیش‌نیازها

برای شرکت در این دوره چه پیش‌نیازهایی لازم است؟

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

این دوره برای شما مناسب نیست اگر...

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

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

اگر انتظار دارید در پایان این دوره یک چک‌لیست از Best Practice داشته باشید، احتمالا ناامید خواهید شد.

اگر هنوز تجربه کار با سیستمی را نداشته‌اید که با گذشت زمان آن‌قدر پیچیده شده باشد که هر تغییری در آن پرهزینه و دردسرساز شود، این دوره برایتان بیش از حد تئوری و انتزاعی به نظر خواهد رسید.

اگر صرفا در حال جمع‌کردن مدرک و Certificate هستید، گزینه‌های سریع‌تر و ارزان‌تری وجود دارد.

آنچه در این دوره یاد می‌گیرید

01

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

02

انسجام طراحی را در طول تغییرات مداوم حفظ کنید.

03

نشانه‌های انحراف تدریجی سیستم را پیش از بحرانی‌شدن ببینید.

04

دینامیک تغییر در سیستم‌های نرم‌افزاری را بشناسید و تحلیل کنید.

05

سرمایه‌گذاری معماری را به زبان کسب‌وکار توجیه و در طول زمان بازبینی کنید.

06

دانش معماری را به فهمی مشترک و ماندگار در تیم تبدیل کنید.

شرکت در دوره

دوره عمومی
۱۰،۰۰۰،۰۰۰ تومان
شروع دوره
۱ شهریور ۱۴۰۵
زمان برگزاری
به وقت تهران
یکشنبه‌ها از ساعت ۱۸ تا ۲۱
نوع برگزاری
آنلاین
تعداد جلسات
۱۴ آموزشی + ۶ کارگاه عملی
۲۰ جلسه
مدت دوره
۶۰ ساعت
دسترسی به ویدیوی جلسات بعد از هر جلسه
ارتباط با گروه کلاس از طریق کانال تلگرام
ساختار دوره
۲۰ جلسه، در دو قالب مکمل
جلسه آموزشی
۱۴

مفاهیم، مبانی و چارچوب فکریِ معماری در گذر زمان

کارگاه عملی
۶

به‌کارگیری مستقیم آموخته‌ها روی یک سیستم واقعی

اگر اینترنت قطع بشه، تکلیف دوره چیه؟

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

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

هنوز سوالی داری؟

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

سوالات متداول تماس با من