מבוא ל Domain Driven Design

האזור הראשון, המודל הקונספטואלי – הוא המהפכני יותר לאנשי תוכנה. אם תוכלו לקחת מ DDD רק דבר אחד – הוא החלק היותר משמעותי.
הרעיון של מודל קונספטואלי לכתיבת תוכנה (עסקית) הוא לא חדש בכלל, אבל DDD חידד ושיפר כמה רעיונות.האזור השני של DDD הוא מורכב, מפורט, והאמת: גם לא כ”כ עדכני (כי טכנולוגיות השתנו, וסגנון ה Microservices פותר חלק מהדילמות). למען האמת, טכניקות ה design של DDD הן מעניינות – אך לא הוכחו כמוצלחות במיוחד בפועל. יש שם רעיונות יפים, ושכדאי להכיר – אבל יותר כרעיונות בודדים ולא כ Framework סדור.

הספר מציג Framework למימוש המודל הקונספטואלי כתוכנה, ומשתמש בעקרונות Object-Oriented בשילוב של רעיונות שאינם Object-Oriented אך הוכיחו את עצמם לאורך שנים. מבנים כמו Aggregate ו/או Repository – הם לא “Object Oriented טהור”. שווה אולי לציין שספרי מידול קודמים נהגו לחתור למודל טהור של “אובייקטים בזיכרון” ולא התייחסו כ”כ לבעיות הארציות כמו – שמירה לבסיס נתונים רלציוני. זה מלכלך את המודל.
למשל:  1.0 EJB היה אמור להיות Framework שמאפשר למתכנת-הממדל לחשוב על אובייקטים ולא לדאוג לבעיות כמו אכסון ושמירה. זה עבד טוב כל עוד היו פחות מ 10 משתמשים במערכת 😉

רעיון כמו Event Sourcing (אותה סקרתי בפוסט קודם) – הוא לא ממש Object-Oriented – אך הוא רעיון מוצלח ושימושי.

זה זמן טוב לציין ש DDD היא מתודולוגיה המכוונת לכתיבת תוכנה עסקית. למשל: מערכת לניהול קמפיין פרסומי, מערכת פיננסית, מערכת לניהול חנות או תחנת מוניות – אלו הם תוכנות “עסקיות”.
Firewall, מודול לזיהוי פנים, או להתאמה של פרסומת ללקוח – הן לא מערכות “עסקיות”, וכנראה פחות מתאימות לשימוש ב DDD.

עוד כמה מילים על “המודל”

המודל הוא תיאור של מציאות (עסקית) מסוימת.
מקובל לתאר אותו ב UML – אבל לא חייבים. מה שחשוב שהמודל יהיה ברור, ושלא משתמע לשני פנים.

אני מעדיף את המונח (המקובל) “מודל קונספטואלי” בכדי לתאר את המודל שהוא רעיוני ולא ממש קוד.
במודל קונספטואלי הישויות הם רעיונות: “חשבונית”, “לקוח”, “ספק” – ולא משנה כ”כ כיצד ממשים אותם. בתוך המודל אפשר לשכוח לרגע מ Scalability, בסיסי נתונים, או בעיות של רשתות תקשורת.

בהמשך הפוסט אשתמש במונח “מודל” – כאשר הכוונה היא למודל קונספטואלי.

שאלה: איזה מודל מהבאים מוצלח יותר, לתיאור ארגון גדול במערכת ממוחשבת לניהול פרויקטים?

מודל ראשון:

מקור: https://martinfowler.com/apsupp/accountability.pdf

או אולי המודל השני?

מקור: https://martinfowler.com/apsupp/accountability.pdf

כמובן שכמו Design של תוכנה, אין “מודל טוב” או “מודל רע”. יש מודל מתאים יותר ומודל מתאים פחות לצורך הקונקרטי.

כשיוצרים מודל זה לא נכון לתאר את המציאות המורכבת במלואה – העולם שלנו הוא מורכב ומלא פרטים. העניין הוא בזיקוק העיקר והדגשת התובנות החשובות לגבי המודל.

כלל מנחה: “!Make the model as simple as possible – but no simpler”

אני אוהב את הדוגמה של אריק על המפה (העתיקה) של חבל ארץ בסין:

מבחינה גאוגרפית המפה היא מעוותת, חסרה פרטים רבים, ומלאת שגיאות!

מבחינת שבט שגר בחבל הארץ הזה היא מאירת עיניים ושימושית למדי – היא מציינת באיזה כיוון מתגורר כל שבט. היא מדגישה את מה שחשוב למשתמשים שלה! מתארת את “הביזנס”.

מפה מודרנית, “מלאה”, ו”מדויקת” – היא כמעט חסרת-תועלת לאותו משתמש.

על אומנות ה Modeling

שימו לב שהרעיונות של DDD לא מתיישבים בקלות עם כמה מתודולוגיות נפוצות – למשל SCRUM.

ב SCRUM, יש תפקיד בשם Product Owner שהוא המתורגמן בין אנשי הביזנס / הלקוחות – למתכנתים. כשיש PO אין צורך לדבר עם לקוחות: ה PO מדבר עם כל הלקוחות, מרכז את התובנות שלהם לתמונה אחידה וברורה – שקל למפתחים לצרוך.

DDD מציגה רעיון שנקרא Hands-On Modeler – המתכנת (להלן “Hands-On”) צריך להיות גם ה Modeler – האדם שמגדיר את המודל, מבין אותו, ומכאן מבין גם את הביזנס ונמצא בקשר עם לקוחות המערכת. זה לא צריך להיות כל מפתח (Every) אלא ייצוג הולם של אנשים מצוות הפיתוח (Any).

שנייה אחת. יש כבר רעיון שכל מפתח צריך להיות איש ה QA של עצמו (TDD?), או הרעיון שכל מפתח צריך להיות איש ה Operations של עצמו (Continuous Deployment?).

האם באמת מפתח יכול להיות גם QA, גם איש Operations, וגם איש Product – ועוד להספיק לכתוב קוד משמעותי?!
כנראה שלא ממש. הסיבה שכל אחת המתודולוגיות הללו “מלבישה” למתכנת “כובע” נוסף חדש – היא כי ממשקי עבודה (“Seams”) הם מקור לתקשורת נחותה יותר (“טלפון שבור”) ואופטימיזציה לוקאלית בכל צד – מתכון מוכך לבעיות.

• ארגונים שאיכות היא עניין מאתגר ומורכב במיוחד עבורם – כנראה ידרשו מהמפתחים גם לעשות QA.
• ארגונים שסביבת הפרודקשיין שלהם מאתגרת – כנראה יידרשו מהמפתחים לעשות גם Operations.
• ארגונים שהתאמת המוצר ללקוח היא חלק מאתגר במיוחד בעיסוק שלהם – יאמצו DDD ו/או Lean Startup.
  • נחדד: אם הלקוח הוא consumer אחד מני רבים – כנראה שגישת ה Lean Startup ושורה של ניסויים – היא עדיפה. אז נרצה שמפתחים יציעו ויבצעו ניסויים.
  • אם הלקוח הוא Domain Expert שיש מעטים כאלו שאפשר לגשת ולתחקר אותם – זה ה Sweet Spot של DDD.

ארגונים שדורשים מהמפתחים שלהם להיות גם וגם וגם – הם כנראה קצת מבולבלים, ולא הבינו עדיין היכן הפוקוס שלהם … 😉

נחזור ל DDD, ופיתוח תוכנה עסקית, שהלקוחות שלה הם עובדי-ידע בעלי מומחיות בתחום כזה או אחר.

ללקוחות יש תפיסה מסוימת של העולם שהם הסכימו בינם לבין עצמם עליה.
בד”כ יש “תפיסה מקובלת בתחום”, עם “התאמות מקומיות” (שחשובות לא פחות, אולי יותר).

אם זו הביזנס הוא תחנת מוניות מוניות אז ה Domain Experts חושבים על “היצע” (נהגים) ו”ביקוש” (נוסעים) ועל אחוז ההיענות של נהגים לנסיעות ו/או אחוז ההזמנות שסופקו. הדרישות החדשות שלהם לתוכנה שנכתבת – יגיעו בעולם המושגים הזה.

כאשר המערכת (תוכנה) איננה ממופה 1:1 למודל הקונספטואלי של הלקוחות – יישום דרישות חדשות עשוי להיות מפרך, ומרובה טעויות:

“אנו רוצים שתשלום יהיה גם במזומן או ב Paypal”
– “אין מצב. אנחנו תומכים רק בכרטיסי אשראי. שינוי עכשיו יהיה מ-ט-ו-ר-ף!”

“אנו רוצים שהזמנה אחת תוכל להכיל שתי נסיעות: הלוך וחזור”
– “אנחנו נאלץ ליצור שתי הזמנות – אחת גלויה ואחת חבויה ולקשר אותן איכשהו. ולחייב שזה אותו נהג ואותו נוסע ועוד כמה דברים…”

“אנו רוצים שהזמנה שכוללת נסיעת חזור תוכל להיות עם נוסעים שונים”
– “הממ… באמת? זה ממש חשוב? נצטרך 8 שבועות בכדי לממש את זה. אולי אפשר לוותר?”

“למה מורכב? תצרו נסיעה עם נוסע אחר. נשים שדה ב UI להזין את זה”
– “אתם לא מבינים. זה ממש מסובך! צריך שה HiddenOrder עכשיו יהיה ExpandedHiddenOrder שנשמר בטבלה אחרת וגם מכיל נוסע שיכול להיות אחר, והטיפוס הזה מדלג על ה Validations כבר יש לנו במערכת עבור הסיפור ההוא של נסיעת חזרה פשוטה…. ו….. ואז….”

“??? ….  אנחנו לא ממש מבינים למה זה הפעם מורכב. תוכנה זה תחום בלתי-צפוי – מסתבר…”

בקיצור: הסתבכנו!

כאשר המערכת (תוכנה) ממופה בקירוב 1:1 למודל הקונספטואלי של הלקוחות – הדרישות החדשות הופכות להיות פשוטות יותר ליישום.

כדי לבנות תוכנה שממופה 1:1 למודל הקונספטואלי – אנחנו צריכים להבין את המודל (הנפלא!) הזה שנמצא במוחותיהם של ה Domain Experts. הבנה שלו תאפשר לנו לקבל דרישות חדשות בהרמוניה.

המודל, למרבה הצער, לא נמצא כקובץ במחשב של הלקוחות. הוא לא קיים כתרשים UML או אפילו לא כ XML – פורמט שאנחנו לא מחבבים.

הוא נמצא שם בראש, לא של אדם אחד – אלא מספר אנשים, ולא פשוט לשלוף אותו.

בעצם: סביר יותר שנוכל רק ליצור קירוב שלו, ולא נוכל לעולם להגיע ל”מודל מדויק”. עדיין, קירוב – הוא טוב בהרבה מכלום.

זהו תהליך ה Modeling.

אם המודל מוכר רק ל PO או לארכיטקט – Corruption הוא בלתי-נמנע.

המפתחים הרי משנים קוד כל הזמן, ואם הם לא מודעים למודל – רק טבעי שיסטו ממנו. כדי לשמור על מודל יציב ונכון, חשוב שחלק מהמפתחים יהיו בקיאים במודל. שהמודל יהיה חשוף לידי כל, ובעצם יהיה כלי עבודה משותף וחשוב כמו New Relic או Github.

כמו כן ה Modelers לא יכולים להיות מנותקים מקוד. הרי המודל בא לשרת תוכנה – ולא להיות מודל “כללי”. תהליך המידול דורש גם הבנה בתוכנה וגם בביזנס.

ברוכים הבאים ל DDD 🙂

דיברנו.
איך ממדלים בצורה טובה? – הייתי ממליץ להתחיל עם הספר Analysis Patterns.

כיצד יוצרים מודל משותף, ומתוקשר היטב? – מדקדקים בשפה!

הרעיון של Ubiquitous Language הוא שנקודת מפתח לגיבוש, שימור, ועדכון המודל הוא הקפדה על שפה משותפת ואחידה – בין כל ה Domain Experts וכל המפתחים.

• המודל הוא עמוד השדרה של השפה המשותפת. הוא אמור להכיל את המונחים החשובים.
• אנו מקפידים על שמות נכונים של אובייקטים, טבלאות בבסיס הנתונים, משתנים וכו’ – ע”פ השפה המשותפת.
  • זה גם נכון למסמכים, מיילים, ודיונים. שימוש בשפה “תקנית” מצופה מכולם.
  • כאשר הקוד יוצא מסנכרון עם השפה – מיישרים אותו חזרה בעזרת Refactoring.
• אם לקוחות משתמשים במונח הרבה – כדאי שזה יהיה אובייקט מרכזי במערכת. אם לא – זהו smell לטעות מידול.
• אם לקוחות משתמשים במונחים דומים לחלופין – חשוב להבהיר את ההבדל! או שיש פה תובנה משמעותית – או שיתיישרו למונח יחיד.
• בגדול, הלקוחות (ליתר דיוק: ה Domain Experts מהביזנס) הם אלו שמכתיבים את השפה. הם מעבירים את הידע שברשותם לפיתוח.

מה קורה כאשר Domain Experts בקבוצה אחת לא משתפים אותה שפה משותפת עם Domain Experts מקבוצה אחרת? למשל: אנשי הכספים לא שותפים לאותה שפה ותפיסת עולם עם אנשי המכירות? (בהנחה ששניהם לקוחות של המערכת)

פתרון אחד הוא ליישר צד אחד. זהו פתרון לגיטימי.

פתרון שני הוא להכיר בכך שיש שתי תפיסות עולם חשובות של הביזנס והשוק – ונכון לתאר את שניהם. במקרה זה אנו מגדירים Bounded Contexts – “הקשרים תחומים” שהם מעין יקומים מקביליים שלכל אחד מודל משלו, ושפה משותפת-אחידה משלו.

Bounded Context (להלן BC) הוא כלי שמומלץ לפרויקטים גדולים ומורכבים. להלן “Tackling complexity in the heat of software” – הסיסמה המתנוססת על ספר ה DDD.

הבחירה באימוץ כמה Bounded Contexts היא נכונות להשקיע עוד עבודה (ייתכן גם כפילות קוד / נתונים) על מנת ליצור לכל סוג לקוח את המודל שיניע את המערכת שהוא זקוק לה.

אם גם אנשי הכספים וגם אנשי המכירות מדברים על “נוסע”, אבל לכל אחד יש תכונות והתנהגויות שונות שלא ממש מסתדרות – אנו ניצור שני אובייקטים:

• “נוסע” בהקשר התחום של אנשי הכספים.
• “נוסע” בהקשר התחום של אנשי המכירות.

ייתכן ושדות אחרים, למשל “ערך גולמי לחברה” – יהיו לא תואמים. סביר להחליט שאנשי הכספים יחליטו שהפוטנציאל העסקי לחברה מנוסע מסוים הוא 4,000 ש”ח, ואנשי המכירות יחליטו שהוא 2,700 ש”ח. כל עוד הם מודעים לקיום הפערים ומאמינים בנחיצותם – זה לגיטימי. ייתכן וגם מחלקת הכספים וגם מחלקת המכירות יעבדו טוב יותר, כאשר לכל מחלקה יהיה מודל המותאם לצרכים שלה.

טבעי כמובן שיהיו שורה של נתונים באובייקט ה”נוסע” שקיימים במודל המכירות ולא קיימים במודל הכספים (וליהפך). התכונה הזו הופכת את המערכת שלנו לפשוטה יותר ליישום (על פני ניסיון לפתח מערכת “ERP” בה יש אמת יחידה בעולם).

גישה (פשטנית) מסוימת קובעת שכל מיקרו-שירות מגדיר Bounded Context משלו.

זה נכון: בעולם המיקרו-שירותים לכל שירות יש בסיס נתונים משלו, ויש כפילויות נתונים מסוימות – בהגדרה, וגם single source of truth.

לומר שכל שירות הוא Bounded Context זו נראית לי כשגיאה גדולה, הליכה רחוק רחוק מדי. סביר לנהל נתונים שונים בכל שירות – אבל לא נראה לי סביר לנהל עשרות או מאות מודלים ושפות אחידות. זה פשוט לא הגיוני.

יש לי שם למצב בו כל שירות מגדיר שפה משותפת-אחידה משלו: “כאוס”.

כאשר יש כמה Bounded Context, חשוב למפות ולשתף את הידע אלו BCs קיימים, מה הגבולות ביניהם, ואלו אובייקטים משותפים (אך בעלי וריאציות שונות) הם חולקים. בסיס הידע הזה נקרא Context Map.
אין איזה פורמט חכם או שיטה מיוחדת לנהל את ה Context Map, עד כמה שזכור לי. כדאי שהניהול יהיה הגיוני ואינטואיטיבי.

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

הפתרון הוא להגדיר Core Model, “מודל ליבה” שמשותף לכולם – אך כולל רק את האלמנטים החשובים ביותר.

לאותו מודל יהיו הרחבות שונות, להם יהיו שותפים צוותים ספציפיים. סה”כ הרעיון הוא הפרדה בין החשוב ביותר (“מודל ליבה”) לחשוב מעט-פחות (“הרחבות למודל”).

כדי שמודל הליבה יהיה יעיל, כדאי (גם בפרויקטים קטנים) לחדד ולזקק אותו לכדי שלמות. שיהיה פשוט. מדויק. עדכני וקל להבנה. איכות המודל תכתיב את איכות יישום ה DDD, בתכלס.

אם DDD היה כרוך רק בהתקנה של תוסף (נוסח apt-get install) – בוודאי רובנו כבר היינו משתמשים בו.

בפועל, זה קצת יותר מורכב.

• קבוצת ה R&D לעתים נתפסת ע”י ההנהלה כמרכז עלות ולא כמרכז רווח: נכון, החברה אולי מרוויחה מהתוכנה שכבר כתובה, אבל הדגש כעת הוא על צמצום בעלויות הפיתוח (פחות עלויות תחזוקה, פיתוח פיצ’רים מהר / זול יותר) ולא בהשקעה להגיע ל”פיצ’ר שתופס בצורה מעמיקה את הביזנס”.
• מפתחים שקועים במידה רבה בטכנולוגיה ובמחשבה כיצד להתנסות / לשלב טכנולוגיה חדשה במערכת – יותר מאשר איך ליצור תוכנה נכונה יותר לביזנס.
  טכנולוגיות חדשות הן מפתח להתחדשות והתייעלות, אך כאשר המיקוד הוא “אימוץ טכנולוגיה החדשה” ולא החדשנות וההתייעלות – התוצאה היא בהתאם.
• ה DB כבר כמה עשורים מקבל מרכז כובד מוגזם בתכנוני המערכת. נכון: הוא כלי רב יכולות, וקל לפשט בעיות ועסקיות ולחשוב עליהן כבעיות של data (“כיצד לוקחים את הנתון הזה, מבצעים עליו עיבוד ומעבירים אותו לשם”) – אבל ההתייחסות ל DB כמרכז המערכת מסתירה מאיתנו תובנות עמוקות יותר על המערכת והביזנס, ולרוב מונעת מ “תכנונים יעילים במיוחד” של המערכת מבחינת DDD – מלהתפתח.
• מבנה המערכת לא מתמפה בצורה פשוטה למודלים העסקיים. 
  • הסיבה: המפתחים בוחרים במידול / מבנה מערכת מתוך חשיבה טכנית גרידא. הם בוחרים בשמות לאובייקטים ולמודולים, כך שיהיו נוחים להם עם הידע הנוכחי שהם – “ידע” שלרוב הוא בעצם בורות עמוקה (סליחה סליחה!) ברזי הביזנס.
  • התוצאה: חלק מהדרישות העתידיות שיגיעו למפתחים יהיו “הפתעת יום כיפור”: הם תכננו את המערכת עם גמישויות X – אבל הדרישות סובבות מסביב לגמישויות Y. השינוי הנדרש הוא ארוך ויקר והמפתחים יעמדו על הרגליים האחוריות להסביר לביזנס ש”הדרישה שלהם לא סבירה”, וש”יאלצו להסתדר בלי”. הם עלולים להיות כמו כלב תוקפני שיש להיזהר ממנו.
    מותר להעמיד את אנשי הביזנס בפני אי נוחות – מלבד הפעמים שאסור.
  • תוצאה בגרסה “משופרת”: המפתחים עובדים בחשיבת Lean. הם לא יצרו גמישויות X כלשהן – ולכן “תסריט יום כיפור” הוא פחות מזעזע עבורם. הם פשוט יבצעו את השינויים הנדרשים במערכת על מנת ליצור גמישות Y. הם אדישים לשינויי הדרישות והם לא יעצרו או יילחמו בביזנס – אבל הם גם יכולים לבזבז זמן רב ב Refactorings הלוך ושוב – כי הם לא מצליחים “להריח” להיכן הביזנס לוקח אותם. הם כמו כלב ידידותי אך עיוור.

ה “System Flexibility Challenge” בין R&D לביזנס, מודגם במטאפורה של מכאניקה. המפתחים מספקים גמישויות x1 ו x2 – ושמחים שענו לצרכי הביזנס, אבל הביזנס בעצם זקוק ל y4 ו y2.