מה מגדיר יום?
מתכנתים מתמקדים לעיתים קרובות בדברים הלא נכונים כשבונים פיצ'רים חדשים.
אולי תחשבו על נתוני backend, כפילות קוד או ביצועים. השאלות האלו חשובות. אבל הן לא השאלות החשובות ביותר.
אני עושה את הטעות הזו לעיתים קרובות. אני מתלהב מתבניות חכמות וקוד נקי. אני מתחיל לכתוב קוד לפני שאני מבין עד הסוף איך המשתמש משתמש בפיצ'ר. ואז אני מבין שהקוד שלי לא תואם את המטרה העסקית.
קחו אפליקציית יומן כדוגמה.
משתמש לוחץ על ה-1 במרץ כדי לסמן חג. אבל האפליקציה מסמנת את ה-28 בפברואר במקום. זה קורה בגלל אזורי זמן (timezones).
המפתח השתמש באובייקט Date. אובייקט Date מייצג רגע ספציפי בזמן.
בטוקיו, ה-1 במרץ בחצות הוא עדיין ה-28 בפברואר בלונדון. אם הקוד שלכם משתמש במתודות UTC כדי לשמור את התאריך, היום זז.
הבאג קיים מכיוון שהמימוש הטכני סותר את הלוגיקה העסקית.
משתמש חושב בימים. משתמש לא חושב ב-UTC offsets או ב-timestamps של מילישניות. הוא חושב: "אני רוצה את ה-14 במרץ".
אם אתם רוצים שהקוד שלכם יהיה אמין, עליכם למדל את הדומיין בצורה נכונה.
ביומן נייר, תאריך הוא פשוט שנה, חודש ויום. אין לו אזור זמן.
אפשר לתקן את הבאג על ידי שמירה על עקביות עם UTC או זמן מקומי. אבל זה רק פלסטר. דרך טובה יותר היא להשתמש במבני נתונים שלא יכולים להיכשל.
במקום אובייקט Date, השתמשו באובייקט מותאם אישית:
• שנה: 2026 • חודש: מרץ • יום: 1
זה מסיר את הזמן ואת אזורי הזמן מהמשוואה. זה הופך את הבאג לבלתי אפשרי.
כן, זה דורש יותר עבודה. אתם צריכים לכתוב פונקציות עזר (utilities) כדי להשוות תאריכים או למצוא את סוף החודש. יש לכם דדליינים וספרינטים לדאוג להם.
אבל מידול נכון של הדומיין יציל אתכם מכרטיסי תמיכה (support tickets) זועמים ושעות של דיבאגינג מאוחר יותר.
כפי שאיריק אוונס אומר ב-"Domain-Driven Design":
"כדי לתקשר ביעילות, הקוד חייב להתבסס על אותה שפה המשמשת לכתיבת הדרישות."
תפסיקו לחשוב רק כמתכנתים. התחילו לחשוב על הכללים העסקיים.