משפט פתיחה קצת מסובך :
בניגוד למערכת IT שמסתובבות סביב ה DB ורק ל5% מהם מתאימה ארכיטקטורה של Domain driven Design (המטוטולוגיה כלומר ההתמקדות בdomain עם שפת ה domain מתאימה לכולם אבל שיכבת ה domain ב BLL עם ה Services , Entities and Value objects מתאימה רק למקצת מפרויקטי ה IT ). הארכיטקטורה של DDD מתאימה לרוב פרויקטי שו”ב ומפשטת את המימוש של המורכבות שלהם .
ניקח כדוגמא את המערכת הבאה של שואב אבק רובוטי אשר נשלט על ידי מחשב Desktop .כלומר המשימה שלו (איזה חדרים לנקות , מתי להתחיל לפעול קבלת התראות על מצב הסוללה )נשלטת על ידי המחשב הDesktop אופן התזוזה של השואב ההחלטה אם המגירה של ה אבק מלאה נשלטים על ידי מחשב פנימי .
Domain
ב Domain driven design של המערכת הזו כאשר בוחנים את המורכבות שלה סביר להניח שיש domain אחד שאחראי על כל הפעולות שלה .אולי אם המערכת היתה שולטת גם על הספריקלים של הכיסוי אש אולי היה טעם להפריד לשני domain ים שונים .
QCRS Query Command Responsibility segregation
בהתאם לעקרונות של QCRS אנו נפצל את המערכת לשניים :
חלק של Query :
שתפקידיו:
- להציג מפה של הבית ובה מיקום השואב כרגע איזה חדרים נוקו כבר איזה חדרים צריך עוד לנקות מכשולים שמוגדרים מראש וכד
- להציג גרף של ניקיון הבית באחוזים
- להציג נתוני Data Mining איזה חדר היה הכי מלוכלך
- להציג נתוני הפעלה של השואב כגון מד סיבובי מנוע , מצב המגירה של האבק באחוזים
- להציג התראות כגון “קשה לי מצטער תנקה קודם כל קצת ידנית ואח”כ אני אכנס לפעולה בחדר הזה “
חלק של Command :
חלק שמאפשר לבעלת הבית לתת פיקוד ישירות לשואב אבק כדוגמת :
עזוב עכשיו מלשאוב את חדר השינה וחוש לנקות את החדר של הילדה (המורה הפרטי לאלגברה צריך לבוא עוד כרבע שעה ואם הוא יראה את הבלאגן שמה לא אדע איפה לקבור את עצמי מבושה )
חלק אשר מנצל את יכולתו החישובית של ה מחשב ה desktop ומנתח לפי הנתונים שזורמים מהשואב היכן כדאי לשואב לעבור עכשיו על מנת לעבוד יותר יעיל ,היכן בהסתמך על נתוני העבר האיזור היותר מגופגפ בבית שבו צריך לתת יותר גז בשאיבה וכד
את החלק של ה command אנו נתכנן ונבנה באמצעות DDD
Entitites
הEntities של המערכת יכולים להיות כדלקמן :
- תחנת עגינה וטעינה
- השואב הרובוטי עצמו
- מכשול שאליו אסור להתקרב כדוגמת ואזה
- חדר בבית (שאותו צריך לנקות )
- הבית עצמו
- תוכנית ניקוי
- סוללה של השואב הרובוטי
לכל ישות ישנו id המורה על יחודיות לדוגמא תוכנית ניקוי עם id של תוכנית ניקוי קצרה לפני שהחותנת באה וכד
ה Entities מכילים State לדוגמא :
הישות של השואב הרובוטי מכילה את ה state של האם נוריות האזהרה דולקות , מצב המקום הפנוי בתא האבק וכד
וגם operational כדוגמת :
הדלק אורות
Value objects
- כמות אבק במגירה
- זמן עבודה נותר
- כמות האנרגיה שנשארה לשואב הרובוטי
Aggregations
הישות סוללה של השואב הרובוטי מחוברת כ aggregate root של ישות השואב , אין לסוללה הזו משמעות ללא הקשר לשואב .
Services
אילו מרכיבים את לב הלוגיקה של המערכת ומכילים את הפעולות שלא ניתן לפנות אל entity ספציפי ולדרוש שיבצעם
דוגמאות :
VCGotoDockingStationService
הפקודה לשואב הרובוטי לחזור לתחנת העגינה אינה יכולה להיות חלק מהישות של השואב הרובוטי עקב כך שהיא מכילה פניה למספר Entities שונים : תחנת העגינה , השואב עצמו , המחשולים שפזורים בדרך ועוד לכן העדפתי לממש אותה כService .
יש עוד הרבה נושאים לדבר עליהם :
- Repositories
- Factories
- השילוב של ה Domain layer בין השכבות של ה application , UI , ו Infrastracture
- המימוש של המערכת
אם אקבל תגובות אשמח להמשיך לכתוב על הנושא
אין תגובות:
הוסף רשומת תגובה