# מערך שיעור: Monolith ו-Strangler Fig📋 מערך מרצה

משך: 2 שעות אקדמיות (90 דקות).

מטרת השיעור: הסטודנטים יבינו מתי מונוליט מספיק ומתי לשקול פירוק, ויכירו Strangler Fig כדפוס הפירוק הבטוח.

בסוף השיעור הסטודנטים צריכים: להסביר יתרונות/חסרונות של כל גישה, לזהות Coupling גבוה/נמוך בקוד קיים, ולתאר תוכנית פירוק הדרגתית.

דגש קריטי: הימנעו מהצגת מיקרוסרביסים כ"השדרוג הבא המתבקש" — זו טעות מושגית נפוצה שהשיעור צריך לתקן במפורש.

---

## מהלך השיעור

| חלק בשיעור | משך | הערות ודגשים |
| --- | --- | --- |
| פתיחה וחיבור | 5 דקות | הזכירו את ה-Task Manager API — "זה מונוליט, וזה תקין!" |
| הבעיה: מתי מונוליט כואב | 15 דקות | צוות גדל, פריסה אחת לכל שינוי |
| יתרונות/חסרונות שני הצדדים | 20 דקות | טבלת השוואה מאוזנת |
| הבעיה: Big Bang Rewrite | 15 דקות | סיכונים — חודשים בלי ערך חדש |
| הרעיון: Strangler Fig | 25 דקות | פירוק הדרגתי, דוגמה מהקורס עצמו |
| תרגול מודרך | 10 דקות | תרגיל 1+2 |

---

## דגשים להעברת השיעור

- זהו שיעור שבו חשוב **לא** ליצור רושם ש"מיקרוסרביסים = מתקדם/טוב יותר" — הדגישו שוב ושוב שזו החלטה תלוית-הקשר (גודל צוות, קצב שינויים), לא שדרוג טכני אוטומטי.
- השתמשו ב-Task Manager API של הסטודנטים עצמם כדוגמה חיה לניתוח Coupling — הרבה יותר משכנע מדוגמה מומצאת.
- Strangler Fig דורש הדגמה קונקרטית של "שלב ביניים" — לא רק "לפני" ו"אחרי", אלא מצב שבו חלק מהמערכת כבר מפוצל וחלק עדיין לא, ושניהם עובדים יחד.

---

## מושגים

**Monolith** — אפליקציה שלמה אחת, נפרסת יחד.
**Microservices** — שירותים עצמאיים, כל אחד נפרס בנפרד.
**Strangler Fig** — פירוק הדרגתי, לא Big Bang.
**Coupling** — רמת תלות בין מודולים.

---

## תרגיל חשיבה

**שאלת פתיחה:** "צוות של 3 מפתחים על Task Manager API קטן — האם הם צריכים מיקרוסרביסים? מה לגבי צוות של 50 מפתחים על אותה מערכת שגדלה פי 20?"

**מהלך:** הובילו לתובנה: אותה מערכת טכנית, החלטה שונה לגמרי לפי גודל הצוות וקנה המידה. 3 מפתחים על מונוליט קטן — מיקרוסרביסים יהיו overhead מיותר. 50 מפתחים שכל שינוי קטן דורש תיאום פריסה עם כולם — כאן מיקרוסרביסים פותרים בעיה ארגונית אמיתית.

**מה המרצה מראה בסוף:** הציגו (בקצרה, ללא קוד מלא) שני "עולמות" מדומים על אותה מערכת — אחד עם צוות קטן ופריסה פשוטה, אחד עם צוות גדול שנתקע מחכה זה לזה על אותה פריסה — הניגוד הסיפורי ממחיש למה ההחלטה תלויה בהקשר ולא בטכנולוגיה עצמה.