על Effective Software Design (או ESD)

תקשיבו: הנה נושא חשוב שמעולם לא כיסיתי בבלוג.

לא התעלמתי לגמרי. כתבתי מסביבו:

• האם אנו זקוקים ל Software Design? (+ כמה תגובות)
• מדוע אנו זקוקים ל Software Design?

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


מהו תהליך ה"דזיין" (כלומר: Software Design) הזה? תהליך שכל מפתח משתתף בו מספר פעמים בשנה?


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

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

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

ניסיתי בתור התחלה לחזור ולהיזכר אלו מקורות לימוד קיימים לנושא הדזיין. הנה מה שמצאתי:

אולי פספסתי מקור או שניים, אבל עדיין המסקנה היא: כמעט ואין מקורות שמלמדים לעשות דזיין!

זה ממש מוזר - כי זה תהליך כ"כ נפוץ וכ"כ מקובל. על איזה בסיס אתם עשיתם דזיין? כיצד לימדו אתכם?

ומכיוון שקיים צורך, היכן היועצים? הקורסים? הספרים? האם אני פשוט מפספס את כולם?

אז איך עושים דזיין - בצורה לא יעילה?

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

דזיין = הצגת הפתרון

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

הפורמט הזה אולי טוב בכדי לשתף בידע את קהל השומעים, אך הוא איננו יעיל באיתור בעיות משמעותיות ושיפורן.

במקום לדון בבעיות הגדולות, פעמים רבות הזמן של הישיבה מושקע בכיסוי מפורט של הפרטים השונים (והברורים מאליהם) של הדזיין. "כן... בחרנו להשתמש ב Database!", "יש לנו controller ו view על מנת לייצר את ה UI!"

אם מטרת הדיזיין היא לשמוע "הממ... כן.. זה נשמע הגיוני.." - אז זה הפורמט הנכון עבורכם!

דזיין = "חפירה" בסכמת בסיס הנתונים

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

המודל הקונספטואלי מרכיב בתוכו הנחות משמעותיות על דומיין הבעיה והפתרון שלה --> שזה מצוין!

סכמה של בסיס נתונים (אם אין מודל קונספטואלי) - היא כלי יעיל להעלות על בעיות מהותיות ושיפורים אפשריים.

שתי הבעיות הן:

• המודל / סכמת בסיס הנתונים היא רק מימד אחד של התוכנה שנכתבת - ואזורים חשובים אחרים כנראה לא זוכים לכיסוי.
• חוק התכנותיקה קובע: רמת הדיון תותאם לרמת הפרטים המוצגים. כאשר מציגים טיפוסים של עמודות, אינדקסים, ו null / not null - הקהל נוטה לחשוב ברמה הזו ולמצוא שיפורים ברמה המשנית הזו. כן, אולי יהיו כמה שיפורים - אבל הפרטים הגדולים יותר של הדזיין נוטים להיעלם מאחורי הפרטים הקטנים והלא חשובים.

תוכנות wireframe, כמו axure, מכילות סט כלים על מנת לייצר low-fidelity wireframes בהם יש פרטים חסרים / לא שלמים / קווים לא ישרים המחצינים את חוסר הבשלות / שלמות של ה wireframe.
כאשר מציגים למשתמשים wireframe מלוטש ומהוקצע - הפידבקים נוטים להיות על הליטוש: צבעים, מיקום של כפתורים, וטקסטים.
כאשר מציגים למשתמשים low-fidelity wireframe - הפידבקים על המהות, ה flow, והתוכן המוצג - תופסים חלק משמעותי יותר.

דזיין = 90 דקות של מסירות - ואז שריקת סיום

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

התוצאה היא זהה: מתחילים לכתוב קוד, מבלי שהגענו להבנה עמוקה של הפתרון הרצוי.
וריאציה לא-יותר-טובה: משקיעים עוד שבוע (וגם ראיתי: חודש!) בדזיין. ברגע שצוות המשימה לא עושה דזיין יעיל - גם חודש לא יעזור. דזיין יעיל לרוב הפיצ'רים - ניתן לעשות ביום-יומיים, כאשר מתורגלים.

סיכום ביניים

לא משנה אם עשינו את אחת הטעויות לעיל, או טעות אחרת. התוצאה היא לרוב זהה:

• יש "סימן v" - כי עברנו תהליך דזיין.
• חלק מהאנשים (לרוב: המנהלים) מתמלאים בביטחון: הנה עשינו "תהליך הנדסי חשוב".
• חלק אחר מהאנשים (לרוב: חלק מכותבי הקוד) - נמצא בעלטה, שכנראה תלווה אותו תוך כדי כתיבת הקוד.
• יש סיכוי טוב שהתיאום בתוך הצוות אינו טוב ואז:
• יהיה צורך לעצור ולדון על הדברים מחדש - תוך זמן קצר.
• הגה אחד ימשך ימינה, הגה שני יימשך שמאלה - והתוכנה תכתב ללא משנה סדורה.

כל שעת ישיבה של 8 אנשים - היא יום עבודה.

האם ימי העבודה שהשקענו בתהליך הדזיין - יחזירו את ההשקעה?
אם לא - האם נכון להמשיך ולהשקיע עוד?

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

אז איך עושים דזיין - בצורה יעילה?

להלן עיקרי הדברים. אציג אותם בתור סוג של "template" למסמך דזיין יעיל.

להזכיר: המסמך הוא לא העיקר - התהליך הוא העיקר. תהליך החשיבה והשיתוף שעוברים האנשים המעורבים.

מה הבעיה העסקית (או הטכנית) שאנו עומדים לפתור?

אם מתמקדים בפתרון, ללא חידוד הבעיה - אזי יש סיכון לאבד את ההזדמנויות ה"שוות" ביותר בדזיין: פתרון אחר לגמרי!

הזדמנות נוספת: קיצוץ אפשרי בפעולות מיותרות. "למה לכתוב קוד multi-threaded? בביזנס אין יותר מ 10-20 בקשות כאלו בדקה!" 

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

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

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

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

הקשר (context)

חשוב מאוד להבין היכן הקוד / מודול / שירות המדובר נמצא ברחבי המערכת הקיימת:

• מי פונה אליו?
• למי הוא פונה?
• באיזה flows גדולים של המערכת הוא מעורב.

זה נשמע טריוויאלי - אבל זה הרבה פעמים זה מידע שחסר, ואף אחד לא מעז לשאול.

תרשים קטן כזה, על הלוח / דף שצולם באייפון / פאוור פויינט - מבאר מאוד את הדברים - ומעמיד אותם על דיוקם.

הוא כמעט תמיד שווה את ההשקעה.

על התרשים שווה להסביר את ה flows החשובים. אחד או כמה. זה יכול להיות בטקסט או בדיאגרמה.

אני אישית מאוד אוהב UML 1.x Collaboration Diagrams.
בגלל שאני רגיל לשרטט אותם - אני גם עושה זאת במהירות.

לפעמים ה flow החשוב - הוא בתוך המודול (או שירות) שלנו.

לפעמים ה flow החשוב - הוא בין המודול שלנו לאחרים.

מה שחשוב הוא לא להציג תרשים בפורמט כזה או אחר.

מה שחשוב הוא "לשים על השולחן" את ה 1 עד 3 flows החשובים ביותר ולראות שהם:

• פותרים את הבעיה שלשמה אנו עומלים, ובצורה טובה.
• שהם אכן הדרך הכי פשוטה שאנו מזהים לפתרון הבעיה.
• שהם משתלבים במערכת הקיימת בצורה יפה, ולא מסבכים דברים. פשטות היא ערך מרכזי.
• שלא עולים מקרי קצה, אמיתיים או בעייתים - שכדי לשים לב אליהם כבר מעכשיו. עולים? מצוין - נחשוב איך מתמודדים איתם. לפעמים מקרה קצה אחר יהפוך את כל הדזיין על פיו.

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

זה השלב לעצור.

Stop!

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

מצאנו את דרך א' כלשהי - שנראה שתעבוד. יהיה אפשר לכתוב קוד באופן הזה שירוץ בצורה נכונה.

הנטייה האנושית היא לקבע, להתרגל, ולהסתגל לאותה דרך א' - כי "היא פותרת דברים" או "זה עובד!".

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

החלטה גדולה מספר 1: מה הייתה הבעיה / דילמה? 

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

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

------

החלטה גדולה מספר 1: איך השירות שלי מקבל נתונים שלהם הוא זקוק?

אופציה א': שירות אחר יעדכן אותנו בכל שינוי דרך RabbitMQ

• יתרונות: פשוט... יעיל ....
• חסרונות: הרבה הודעות ....

אופציה ב': השירות שלנו יקרא לשירות השני בכל פעם וישלוף את הנתונים.

• יתרונות: פחות הודעות ברשת. הנתונים יותר up-to-date
• חסרונות: התלות "מרגישה" לא נכונה.

בגלל xyz בחרנו באופציה א'.

------- 

תיאור שכזה הוא בסיס לסיעור מוחות איכותי.

• סיפקנו לאנשים בדיון מידע עומק מספיק על מנת שיעקבו אחרי ההחלטה שלנו.
• אנו משקיעים זמן בדברים החשובים ביותר - הרי זו "החלטה גדולה"

חלק גדול מפריצות הדרך בסיעורי מוחות שכאלו קורים כאשר המשתתפים מסכימים עם ההחלטה - אבל לא עם ההנחות!

מישהו אומר: אבל לא לקחתם בחשבון את חסרון x באופציה א'. זו בעיה ממשית כי....

ערעור הנחות היסוד מוביל לעתים לבחירה באופציה השנייה שהועלתה, ו/או ליצירה של אופציה שלישית.

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

אני ממליץ להתעקש על דיון ב 2-3 "החלטות גדולות" עבור בדזיינים משמעותיים.

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

המודל

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

הדיון במודל יהיה יעיל יותר כאשר:

• נשמיט שדות לא חשובים. created_at ו updated_at אולי הם שדות רצויים - אבל יש סיכוי טוב שהם לא באמת חשובים לדיון. כלל זה גם טוב אם המודל מאוחסן ברדיס, או MongoDB - למשל.
• נשמיט טיפוסים של בסיס הנתונים, כדי להימנע מדיונים משניים. 
• הדיון על varchar vs. char vs. text ב postgreSQL הוא מעניין - אבל לא מצדיק את ההשקעה ברוב המוחלט של הפיצ'רים.גם אם מדובר בדיון 1 על 1 - הרשו לעצמכם לדלג על הדיון הזה.
• נתאר את השימושים העיקריים של ה data, אם מדובר בכמויות / קצבים משמעותיים. 
• דיון קצר על אינדקסים ומבנה הסכמה, לאור השימוש המצופה - כן יכול להיות דיון משמעותי ששווה את הזמן.
• כמו כן: העובדה שיש לנו מיליון אובייקטים / רשומות שנוספים כל יום - הוא מידע שעלול לערער הנחה ו/או חלק אחר בדזיין של המערכת. דיון על כמויות שימוש במודל עשויות להעלות נקודות שלא היינו חושבים עליהן אחרת.

דוגמה: הצגה פשוטה ויעילה של מודל. מתמקדים בפרטים העקרוניים / משמיטים את הפרטים המשניים.

צ'ק ליסט

לכל ארגון ולכל מערכת - יש את הטעויות הנפוצות שלה. בעיות אבטחה או privacy, חשיבה על האופי המבוזר של המערכת, אי חשיבה על scale, תצורת פרודקשיין, איך לקוחות מסוג מסוים משתמשים בפועל במערכת, וכו' וכו'.

הרכיבו לעצמכם את הצ'קליסט הקצר, היעיל, והכי מחובר לקרקע שאתם יכולים - על מנת לנסות ולתפוס בעיות בזמן תהליך הדזיין. עברו על הצ'ק ליסט לבד או ביחד - מה שעובד הכי טוב.

-----------

תהליך דזיין כמו שתואר למעלה אפשר לעשות ביום-יומיים, עם צוות מיומן.

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

אם כל מפתח ישתתף בדזיין כל ספרינט, הסיכויים להשתפר ו"לשפשף" את התהליך - גדלים.

כמה עצות כלליות:

זדיין הוא לא נוסחה מתמטית

ולכן זה לא סוג הפעילות שיעיל לעבוד עליו לבד לאורך זמן.

אם אני יושב עם עצמי לבד בשקט ו"חושב על דזיין" - אחרי שעה בערך אני מפסיק להיות יעיל. אני זקוק להפרייה-הדדית. לדיונים עם אנשים. לספר, לשמוע, להחליף רעיונות.

אני אישית מוצא השקעה של שעה-שעתיים-שלוש בה אני "משרבט" קוד, שלד של flow כפי שאני מתאר לעצמי אותו - כיעילה ל"הזרמת חמצן" לחשיבה. 

הלו? - שנות התשעים עברו

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

רדו מזה! חשבו על פשטות, על תחזוקה, על הרמוניה עם המערכת הקיימת, על עקרונות SOLID או GRASP.

עשו דברים הגיוניים, שעובדים לביזנס שלכם.

דזיין הוא תהליך של קונצנזוס

שזה אומר כן... תהליך חברתי. לא הדבר שהכי טבעי לכל אנשי התוכנה על כדור הארץ.

במהלך הדזיין חשוב להגיע להבנות משותפות, ולפשרות במקומות הפחות משמעותיים.

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

אם אתם משקיעים שעות בדיון האם להעביר את שדה ה data ב json ברמה העליונה או רמה משנית - אז .... באמת חבל.

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

הדזיין לעולם לא נגמר

מסמך הדזיין - יעלם לו בדרך כלל בתיקיה בה הוא נשמר. אחרי חודש-חודשיים - הוא כבר כמעט לא רלוונטי.

יש נוסחה שאומרת שההתיישנות של מסמך הדזיין = המרחק הפיסי שלו מהקוד x אורך המסמך.

ולכן, מסמך דזיין שמופיע כשני עמודים של readme.md בתוך ה git repository - הוא זה שהסיכוי שלו להישאר רלוונטי הוא הכי גדול.

הרבה יותר חשוב מהדזיין, או מישיבת ה Review (אם יש כזו) - הוא הידע, ההבנות, והחשיבה שנעשו. התהליך שעברנו בזמן העבודה על הדזיין.

"חשיבת דזיין" תמשיך להיות בשימוש תוך כדי כתיבת הקוד, תוך כדי Refactoring בקוד, או תוך כדי דזיין / עבודה על הפיצ'ר הבא באותו האזור של המערכת.

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

שיהיה בהצלחה!

מבוא ל Domain Driven Design

Domain Driven Design, או בקיצור DDD היא מתודולוגיה שהוצגה בשנת 2003, בספר בשם דומה.

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

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

בעצם - הוא היה דיי אלמוני.

עד היום, אין ערך בוויקיפדיה על שמו. פרופיל הלינק-אין שלו לא מזכיר דבר לפני 2003, ואפילו גוגל, אבוי לבושה, טועה - ומקשר את הספר שכתב לפרופסור כלשהו להיסטוריה - בשם דומה. בכדי למצוא פרטים על אריק הנכון פרטים - צריך להתאמץ!

פאדיחה!

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

הפרט ההיסטורי שיכול להשלים חלק מהתמונה הוא הפוסט הבא, דף הפרופיל של אריק ב WikiWikiWeb, הוויקי הראשון בעולם - שהוקדש לרעיונות בהנדסת תוכנה:

את WikiWikiWeb תחזקו Kent Beck ו Ward Cunningham, וברגע שדמות מוכרת כמו Kent Beck התלהבה מהספר - הדלתות נפתחו, וכמעט כל עולם התוכנה שמע על הספר.

ב 2003, וקצת אחריה - הספר נחשב ליצירת מופת של הנדסת תוכנה.
אבל מכיוון שזהו ספר ארוך (560 עמודים), ושאת הרעיונות שבו לא קל לממש - העניין בו דעך. אפילו נאמר עליו שהוא מציג רעיונות נהדרים - שלא רבים סיפורי ההצלחה של היישום שלהם בפועל.

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


--- fast forward ---


בערך ב 2014, כשאנשים כמו Martin Fowler, ו James Lewis ניסו להסביר לעולם את רעיונות הארכיטקטורה של MSA - הם השתמשו במונחים כמו Bounded Context וחזרו להזכיר את DDD. רעיון משפיע אחר הוא הרעיון של Event Sourcing (המופיע בספר פשוט כ "Domain Events") - שיש לו קשר חזק לבאזז אחר: CQRS.

אריק חזר להופיע בכנסים חשובים, ואפילו יש כמה כנסים חדשים שמוקדשים ל DDD (למשל: DDD Europe). במשך השנים יצאו כמה ספרים נוספים על DDD (אריק הוציא תקציר "reference" לספר המקורי) וניתן היום למצוא מקורות כמו DDD Weekly - שהחל את דרכו רק בשנה שעברה. כמות הכתבות ב Medium והדיונים ב Hacker News לגבי DDD (ע"פ תחושה אישית ולא מדויקת שלי) - והלכים וגדלים.

DDD חזר למרכז הבמה!


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

הנה מתחילים!

אז הנה זה לפניכם, רשימת ה Patterns שמציג הספר והקשרים ביניהם:

מה... אתם צריכים דקה בכדי לעכל את התרשים? ... שעה?........ יותר?!


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

DDD מציג רעיונות רבים, אבל מה העיקר?
מהם 3-4 הרעיונות הכי חשובים שהבנה שלהם יכולה לתרום לשיפור מעשי במאמץ הקטן ביותר? (זו תמיד שאלה טובה...)


רואים בתרשים למעלה את ארבעת המעגלים הגדולים ביותר? - אלו הם גם הרעיונות החשובים ביותר במתודולוגית ה DDD.
אמנם שלושה מהם מכוסים בספר בשלב מאוחר (פרקים 14 ו 15 !!) - אולם אריק בעצמו מספר שזו הייתה טעות, שהוא לא נתן לרעיונות הללו את הדגש הנכון. שאם היה כותב את הספר מחדש, אלו ככל הנראה היו פרקים 2 ו 3.

בגדול אפשר לומר שמתודולוגית ה DDD עוסקת בשני אזורים:

• בניית מודל קונספטואלי - שמתאר בצורה "טובה" את המוצר, ואת הביזנס, בהקשר של תוכנה.
• מיפוי המודל הקונספטואלי ל 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"
- "אין מצב. אנחנו תומכים רק בכרטיסי אשראי. שינוי עכשיו יהיה מ-ט-ו-ר-ף!"

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

יותר גרוע: ככל שבאות עוד ועוד דרישות - מודל התוכנה "יתעקם" ויתרחק מהמודל של ה Domain Experts. התהליך הזה נקרא ב DDD בשם Corruption.

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

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

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

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

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

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

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

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

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

זהו תהליך ה Modeling.

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

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

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

ברוכים הבאים ל DDD :-)

העקרונות הראשיים של DDD (בקצרה)

המודל

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

Ubiquitous Language (שפה משותפת-אחידה)

פירוש מילולי יותר של Ubiquitous הוא "נמצא בכל מקום בו-זמנית". דומה מאוד ל Universal.

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

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

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

ללא שימוש פעיל ב Ubiquitous Language - המודל הופך לעוד מסמך Design שרק בדדים מכירים - ומושפעים ממנו.

Bounded Context

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

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

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

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

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

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

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

כמובן שגישה זו מזמינה בעיות Consistency במערכת (לא דבר טוב) - ולכן חשוב על כל סוג נתון מרכזי (שם, אימייל, מספר טלפון) - להגדיר Single Source of Truth, קרי איזה אובייקט ("נוסע-כספים" או "נוסע-מכירות") הוא מקור האמת במידה של חוסר התאמה.

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

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

Bounded Context ועולם ה Micro-services

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

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

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

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

Context Map

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

Core Domain

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

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

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

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

כמה קשיים ביישום 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.

קשיים בעבודה משותפת: פיתוח ו Domain Experts

Communications usually fails, except by accident"  -- Osmo Wiio"

למעלה: איך שהפיתוח עשוי להיתפס לפעמים ע"י הביזנס - מקור מקור: nytimes
למטה: איך שהביזנס עשוי להיתפס לפעמים ע"י ה R&D - מקור: spiritscienceandmetaphysics

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

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

ה Domain Expert מבין עניין. לאחר שיחת היכרות של שלושים דקות הוא מסדר לנו את הדברים בראש ב Domain שלו. משם נפגשים עוד כמה פעמים, תוך כמה מפגשים - אנחנו כבר "מביני עניין" ב Domain! אנחנו מגדירים במשותף מודל - וזה ממש עובד יפה!. משם ממשיכים לפיתוח, אנחנו עושים את העבודה שלנו (נהדר, כרגיל) ויוצאת מערכת פצצה שמזניקה את הביזנס - וה Domain Experts אסירי תודה לעד!
הללויה!!

רק שזה לא עובד כך.

פערי השפה / תפיסה בין איש פיתוח ל Domain Experts הם גדולים - ולוקח זמן מה להתחיל ולגשר עליהם.

"למד אותי את הדומיין!" היא קריאה שתעורר לרוב השתאות ממש כמו הבקשה "צייר לי כבשה!"

"הדומיין"? ה Domain Expert לא רגיל ללמד את תחום המומחיות שלו, לזקק את הידע הזה, ולהנגיש לאדם מתחום אחר. רוב הסיכויים שהוא ינסה לעשות דבר כזה פעם ראשונה.

רוצים להיות אנשי כספים? אין בעיה. נתחיל במשימות פשוטות ותוך חצי שנה, אם תתאמצו - תבינו עניין!

רוצים להבין את תמצית הידע, בחתך ששימושי לאנשי תוכנה (שאין לנו מושג כיצד באמת הם עובדים) תוך כמה פגישות? - קצת יותר קשה...

יכול להיות שה Domain Expert שלכם לא נראה כזה "מומחה". מומחה עסקי הוא לא תמיד אדם אנליטי שיודע לחדד תובנות בזו אחר זו. לפעמים גם הוא בעל מומחיות בינונית.

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

יש גם סיכוי טוב שיש פער אמון שצריך לגשר עליו. במיוחד אם ה Domain Expert הוא משתמש מתוסכל של מערכת מחשוב כלשהי שפותחה ב R&D...

הכל יכול להיות.

פעם אמרו ש eXtreme Programming לא מתאים לכולם.

אז גם DDD לא מתאים לכולם. הוא מתאים לגוף R&D שזו האג'נדה שלו, ולאנשי תוכנה בעלי כישורי תקשורת טובים, והרבה מוטיבציה להיכנס לעולם הביזנס - בהשקעה הנדרשת.

איך מכשירים אנשי תוכנה לעבוד עם Domain Experts? למדל?

אני בהחלט לא מסוגל לענות על השאלה הזו על רגל אחת, ואולי גם לא מסוגל בכלל :-)

סיכום

כמו בפוסטי עבר: אם אתם מעוניינים רק לספר לחברים שאתם עושים DDD וזה "מה-זה מגניב!", אתם יכולים להתעלם מכל הנאמר בפוסט - ופשוט להצהיר זאת כבר עכשיו. אני מרשה.

אם חשבתם שתצאו מהפוסט הזה עם Patterns מגניבים שאפשר לממש מחר בבוקר (בעולם המיקרו-שירותים) - ייתכן ואכזבתי אתכם. סליחה.

הפוטנציאל של DDD להשיג שיפור משמעותי במקצוע התוכנה - הוא גדול, במיוחד מסביב לאזור המידול. הבעיה: קשה למצוא את האנשים שיפיקו ממנו את המירב. ייתכן גם שהם לא העובדים הטיפוסים של סטאראט-אפ מגניב, שבדיוק מחלקים את הזמן בין משחק בין Vue.js ו Docker.

אציין משהו לא מגניב: אני נתקל בפעילות רבה במיוחד בכל הנוגע ל DDD דווקא בעולם הדוטנט / #C (למשל: naked objects - אבל גם הרבה מעבר לזה). אני מניח שמפתחים הרבה יותר "תוכנה עסקית" על סביבת NET. של מייקרוסופט מאשר על סביבות אחרת - או לפחות הם מזהים את עצמם ככאלה.

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

למה אני אומר את זה? - אני זקוק לפוסט המשך בכדי להסביר...


שיהיה בהצלחה!