מערך שיעור: Bounded Context

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

מטרת השיעור: הסטודנטים יבינו למה חיתוך לפי DB/שכבה טכנית שגוי, ויתכננו Bounded Contexts לפי יכולת עסקית.

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

דגש קריטי: דוגמת “Customer שונה בכל קונטקסט” היא הליבה הרעיונית של השיעור — תנו לה זמן ודוגמאות מרובות.

מהלך השיעור#

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

• דוגמת “Customer שונה” צריכה כמה איטרציות — לא מספיק להראות פעם אחת, תנו לסטודנטים להציע עוד דוגמאות משלהם (Product בקטלוג מול מלאי, User באימות מול פרופיל) כדי שהרעיון “יתקבע”.
• זהו שיעור מושגי-בעיקרו — אין הרבה קוד להדגים, יותר דיאגרמות ודיון. ודאו שהמעורבות נשארת גבוהה עם שאלות פתוחות.
• קשרו קדימה במפורש לפרויקט הצוותי (Collector/Analyzer/Alert/Dashboard) — התרגיל השלישי כבר מכין לכך.

מושגים#

DDD — תכנון סביב הדומיין העסקי. Bounded Context — גבול סביב יכולת עסקית שלמה. Ubiquitous Language — מונחי קוד זהים למונחי עסק.

תרגיל חשיבה#

שאלת פתיחה: “מהי המילה ‘הזמנה’ במערכת שלכם — האם היא אותו דבר בדיוק בשירות המלאי, בשירות המשלוחים, ובשירות החיוב?”

מהלך: הובילו לתובנה: כנראה לא! שירות המלאי מתעניין ב"אילו מוצרים ובאיזו כמות"; שירות המשלוחים מתעניין ב"לאן ומתי"; שירות החיוב מתעניין ב"כמה ומתי שולם". שלושתם “מדברים” על אותה הזמנה אמיתית, אבל כל אחד רואה בה היבט שונה לגמרי — זו בדיוק המשמעות המעשית של Bounded Context.

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