Domain Driven Design - מחשבות - הקדמה
בסדרת המאמרים הבאה אני אקרא יחד איתכם את הספר domain driven design ואשתף בתובנות שאני לומד
יותר ויותר חברות מבינות את החשיבות של פיתוח המחקר והלמידה של העובדים שלהן.
לשמחתי הרבה, גם אני עובד במקום כזה ויש לנו תקציב לימודים של עד אלף ש״ח בשנה.
אז מה עשיתי איתו? כמובן הזמנתי ספרים.
אחד הספרים שהזמנתי הוא Domain Driven Design של Eric Evans.
והחלטתי שכדי שבאמת אקרא אותו, אני אעשה סיכום או קריאה מודרכת של הספר יחד איתכם.
כל פעם שאסיים פרק, אעלה פוסט (וסרטון לטיקטוק) עם סיכום של מה שקראתי ואולי גם מה אני חושב.
אז יאללה, לפרק הראשון.
Domain driven design #תכנות #הייטק #מתכנת #מדמח #לומדים_עם_טיקטוק
מבוא
טוב אז אני מתחיל במבוא שכתב חבר של אריק, מרטין פאוולר. שהוא מתכנת מוכר בזכות עצמו.
והנה רשימת הנקודות שהוא מעלה על הספר ולמה הוא חושב שזה ספר חשוב.
מורכבות היא ענין בילט-אין לתוכנה
כן, זו נקודה נכונה מאוד. אם מה שאתם יוצרים הוא מורכב, למשל אתם כותבים תוכנה למפעל נורא גדול, אין לכם דרך להפוך את הפתרון עצמו לפחות מורכב, הוא עדיין יהיה חייב להתמודד עם כל המורכבות של המוצר עצמו.
כל מה שתוכלו לעשות הוא לשלוט במורכבות.
Domain Model
כדי לשלוט במורכבות אנחנו צריכים domain model, הוא לא מסביר כאן מה זה אומר, אני מניח שיהיה יותר פירוט בספר עצמו.
אבל בשביל זה יש לכם אותי 😜.
Domain Model היא הדרך שלנו לתאר את העולם האמיתי בצורה שתתאים לתוכנה.
שזה אומר, לכתוב את המודלים השונים ואת הקשרים והתלויות שלהם.
זה בדרך כלל נראה ככה
אבל בשביל לכתוב domain model טוב ונכון, צריכה להיות לנו מסגרת טובה.
צריכה להיות לנו שפה מוגדרת שאנחנו יודעים להשתמש בה ושתתן לנו את הכלים לכתוב מודלים נכונים.
לא להפריד את הקונספט מהמימוש
יש מקומות שעיצוב המודל והתכונה קורה לפני ובמנותק מתהליך הפיתוח עצמו.
אבל אי אפשר באמת לנתק את הארטיטקטורה של המוצר מהפיתוח. גם בגלל שצריכים לדעת מה המגבלות של הפיתוח.
אבל בעיקר, כי השפה צריכה להיות משותפת גם לצוות העיצוב וגם לצוות הפיתוח. רק אם כל הצוותים מדברים את אותה שפה, אפשר באמת לבנות מודל נכון שימשיך לתפקד.
מודל דינמי
דבר נוסף שחשוב לזכור הוא שאין דבר כזה באמת לעצב משהו אחד ואז לפתח אותו. זה אולי נשמע לכם מובן מאליו, אבל בעבר כשהיו כותבים בשיטת waterfall, היו מעצבים פתרון, ואז יושבים וכותבים אותו עד הסוף.
מה אם יש בעיה בפתרון? אנחנו נדע מזה רק בסוף.
זו כמובן גישה בעייתית מאוד, מעצבי המודל חייבים לקחת בחשבון שדברים ישתנו תוך כדי פיתוח. אולי פתאום נגלה שיש עוד שלב באמצע שלא חשבנו עליו מראש. אולי נגלה שחלק מהדברים לא באמת אפשריים בלי לשנות את המודל.
מודל טוב הוא מודל שבנוי להיות דינמי, וכדי להצליח לכתוב מודל דינמי אנחנו צריכים ללמוד את השפה של domain driven design.
ללמוד מטעויות
מרטין ממש אוהב את אריק, או זה לפחות מה שהוא כותב 😀
אחד הדברים שהוא הכי אוהב בספר זה שאריק לא נמנע לכתוב כל הטעויות שלו, וזה דבר מצוין.
כי אפשר ללמוד הרבה דברים מההצלחות של מישהו, אבל אפשר ללמוד הרבה יותר מהטעויות.
מה אתם חושבים?
אז זהו, זו הייתה ההתחלה, הסיכום הראשון שלי. ואשמח לשמוע מה אתם חושבים.
אהבתם את הסיכום? רוצים שאמשיך?
תכתבו לי בתגובות או במייל חוזר (או בטיקטוק)