Domain Driven Design - מחשבות - מבוא
בסדרת המאמרים הבאה אני אקרא יחד איתכם את הספר domain driven design ואשתף בתובנות שאני לומד. והפעם המבוא לספר, למה הוא נכתב ולמי הוא מיועד.
Domain Driven Design - מחשבות - הקדמה
בפרק הקודם סקרנו את ההקדמה שכתב חברו של אריק, מרטין פאוולר.
עכשיו אנחנו קוראים את ההקדמה של אריק. בהקדמה אריק מסביר למה כתב את הספר, מה יהיה בו ולמי הוא מיועד.
אז קדימה! בואו נתחיל.
למה?
עשרות שנים שאנשים כותבים קוד, ועשרות שנים שיש לנו מעצבי קוד או ארכיטקטים. אבל, אומר אריק, עוד לא הייתה לנו מתודולוגיה מסודרת וכתובה לעיצוב של קוד.
למרות שלא היה משהו מסודר, אנשים כן עיצבו מה שאומר שכן הייתה איזו מתודולוגיה רק שלא נתנו לה שם.
אז אריק נתן לה שם - Domain Driven Design.
שלושה סיפורים
אריק מספר על שלושה פרוייקטים שיצא לו להכיר.
בראשון היה דיזיין, מראש הבינו את הדומיין וכתבו לו מודלים. היה קשר טוב בין הפיתוח והעיצוב והמודל הלך והתפתח עם הפרוייקט.
הפרוייקט הזה זכה להצלחה כי הוא ידע להתאים את עצמו בקלות לדרישות המשתנות של המוצר, וזאת בשל העבודה שידענו מה המודל של הפרוייקט, המורכבות שלו הייתה מסודרת ומעוצבת, ולכן השינויים היו קלים יותר.
לעומת זאת, הוא מספר על פרוייקט אחר, שני. שם לא היה דיזיין.
אחרי הגרסה הראשונה שהייתה מאוד מוצלחת, הלקוח התלהב ורצה עוד הרבה מאוד פיצ׳רים.
הצוות המקורי פנה לאריק שיצטרף אליהם, אבל הם לא רצו לעשות עיצוב, הם לא בנו מודל מבוסס דומיין.
אריק סירב.
התוצאה הייתה שהקוד שלהם הפך מהר מאוד ללגסי, הם לא הצליחו להוציא גרסה שניה בזמן, ורק אחרי שנה הוציאו גרסה שהיו בה מעט מאוד מהפיצ׳רים שהלקוח ביקש.
בפרוייקט השלישי דווקא היה דיזיין, והגרסה הראשונה הייתה מאוד מוצלחת. אבל למרות זאת בגרסה השניה הם נתקלו באותן בעיות שהיו בפרוייקט השני.
הסיבה הייתה שלא היה קשר טוב בין הפיתוח לעיצוב. מה שגרם לכך שהפיתוח לא באמת הבין את הדומיין, ולא באמת עבד לפיו. עם הזמן הדומיין הפך להיות מנותק לחלוטין מהקוד.
והקוד הפך שוב, ללגסי קוד שקשה מאוד לפקטר.
אתגר המורכבות
יש הרבה אלמנטים שיכולים לגרום לפרוייקט לסטות מהמסלול.
אבל הדבר העיקרי הוא מחסור בעיצוב.
כאשר המפתחים לא מכירים את המורכבות של הפרוייקט, ולא מבינים את הקשר בין מה שהם כותבים ללוגיקה של המוצר, אז הם גם לא כותבים קוד שאפשר לשנות ולשפר לפי השינויים בדרישות.
אנחנו לא מדברים על עיצוב של קוד מבחינה טכנית, כמו איך מעצבים טבלאות בDB, או מה הדרך הנכונה להרים cluster של שרתים בAWS.
אנחנו מדברים על המורכבות של הפרוייקט עצמו, על הקשר שלו למוצר ולמורכבות של החיים האמיתיים.
אם הלוגיקה לא מסודרת לנו בראש, אז קשה מאוד לתפוס ולנהל את המורכבות של הפרוייקט.
מטרת הספר
אריק מונה שתי תובנות עיקריות שהוא רוצה שניקח מהספר:
עבור רוב פרוייקטי התוכנה הפוקוס העיקרי צריך להיות על הדומיין ולוגיקת המוצר
המורכבות של הדומיין צריכה להיות כתובה כמודל
דיזיין מול פיתוח
זה אמנם ספר על ארכיטקטורה ועיצוב, אבל הוא הולך לתת בו הרבה דוגמאות אמיתיות, כי בלי לקשר את זה לקוד אי אפשר יהיה להעביר את הרעיון באופן קונקרטי שיתחבר למציאות העבודה ביום ליום.
ברמת העיקרון זה אמור להתאים לכמעט כל פרוייקט ולכמעט כל שפה ומתודולוגיה.
אבל צריכים להתקיים לפחות שני תנאים:
שיטת הפיתוח היא איטרטיבית, כלומר agile. שיטה שבה עובדים עם איטרציות קטנות של פיתוח שבה מפתחים, מפקטרים וכן הלאה.
קשר קרוב וצמוד בין המפתחים והארכיטקטים.
אריק עצמו מאוד מחובר לגישת Extreme Programming אבל כל שיטת agile היא טובה.
הרבה מפתחים הניחו בטעות שagile אומר שלא צריכים דיזיין. אבל אין טעות גדולה מזו.
אמנם אנחנו לא מעצבים הכל מראש ואז מתחילים לכתוב בלי סוף, כמו שיטת הwaterfall הידועה לשמצה, זה בהחלט נכון. אבל זה לא אומר שלא צריכים בכלל design.
ההיפך הוא הנכון, XP אפשרי רק אם יש לנו מודל!
בלי מודל אנחנו נאבד ידיים ורגליים בפרוייקט, הוא יהפוך להיות ענק ומסורבל ולא נהיה מסוגלים לעבוד באיטרצית מהירות של פיתוח ושינוי כמו שאמורים לעשות בagile.
למי מיועד הספר?
למפתחים שעובדים בשיטת Object Oriented. כי בעצם הוא מדבר הרבה על מודלים ואיך לכתוב אותם נכון.
לכל רמת ניסיון. כל מפתח.ת יוכלו ללמוד משהו חדש ולהשתמש בdomain driven design לצרכים שלהם בארגון.
למשל הtech lead יוכל לדבר על פיקטורים נדרשים עם שאר המפתחים בשפה שכולם יכירו ויבינו.
לארכיטקטים כמובן, כדי לעזור להם לתרגם את הסיבוכיות והמורכבות של הדומיין למודלים של קוד.
גם מנהלי מוצר יכולים להרוויח הרבה מהספר, כדי להבין טוב יותר את הקשר בין התוכנה והמוצר, וכדי שתהיה להם שפה אחידה מול הפיתוח.
למרות שגם המפתח הבודד יוכל להפיק תועלת מהספר, התועלת העיקרית שלו מגיעה מצוות וארגון שלם שפועל בשיטה. כדי לדבר באותה שפה ולחלוק את אותה מודל, להבין תלויות בין הצוותים השונים והחשיבות של כל חלק למטרות החברה.
לסיכום
אג׳ייל זה לא תירוץ לקוד מכוער. להיפך!
קוד שמעוצב בצורה נכונה בדומיין מודל שקשור למטרות החברה, ומתעדכן בתדירות גבוהה, הוא קוד דינמי וחזק שמאפשר שינויים מהירים ואג׳יליות אמיתית.