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

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

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

היסוד: מהי בטיחות טיפוסים ב-EDA?

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

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

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

מדוע בטיחות טיפוסים קריטית ב-EDA?

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

• הפחתת שגיאות זמן ריצה: היתרון הברור ביותר. כאשר צרכנים מצפים לאירוע `OrderPlaced` עם שדות ספציפיים כמו `orderId` (integer) ו-`customerName` (string), בטיחות טיפוסים מבטיחה שהם לא יקבלו אירוע בו `orderId` הוא מחרוזת, מה שיוביל לקריסות או התנהגות בלתי צפויה.
• שיפור פרודוקטיביות מפתחים: מפתחים יכולים להיות בטוחים בנתונים שהם מקבלים, מה שמפחית את הצורך בקידוד הגנתי נרחב, אימות נתונים ידני וניחושים. זה מאיץ את מחזורי הפיתוח.
• יכולת תחזוקה משופרת: כאשר מערכות מתפתחות, קל יותר לנהל שינויים. אם מבנה אירוע צריך להתעדכן, סכימות ברורות וכללי אימות הופכים את זה ברור אילו מפיקים וצרכנים מושפעים, מה שמקל על אבולוציה מבוקרת.
• דיבוג ותצפית טובים יותר: כאשר מתעוררות בעיות, מעקב אחר זרימת האירועים הופך לפשוט יותר. ידיעת המבנה הצפוי של אירוע עוזרת לזהות היכן עשויה להתרחש שחיתות נתונים או טרנספורמציות בלתי צפויות.
• מאפשר אינטגרציה: בטיחות טיפוסים פועלת כחוזה API ברור בין שירותים. זה בעל ערך במיוחד בסביבות הטרוגניות בהן צוותים שונים או אפילו שותפים חיצוניים משתלבים במערכת.
• מאפשר תבניות מתקדמות: תבניות EDA מתקדמות רבות, כגון Event Sourcing ו-CQRS, מסתמכות במידה רבה על שלמות וצפויותיות של אירועים. בטיחות טיפוסים מספקת ערבות יסוד זו.

תבניות הודעות מפתח בארכיטקטורות מונעות-אירועים

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

1. תבנית פרסום-מנוי (Pub/Sub)

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

יישום בטיחות טיפוסים ב-Pub/Sub:

• מאגר סכימות (Schema Registry): זהו כנראה הרכיב הקריטי ביותר לבטיחות טיפוסים ב-Pub/Sub. מאגר סכימות (למשל, Confluent Schema Registry עבור Kafka, AWS Glue Schema Registry) פועל כמאגר מרכזי לסכימות אירועים. מפיקים רושמים את סכימות האירועים שלהם, וצרכנים יכולים לאחזר סכימות אלו כדי לאמת אירועים נכנסים.
• שפות הגדרת סכימות: השתמשו בשפות הגדרת סכימות סטנדרטיות כמו Avro, Protobuf (Protocol Buffers), או JSON Schema. שפות אלו מאפשרות הגדרה פורמלית של מבני אירועים וסוגי נתונים.
• סריאליזציה/דה-סריאליזציה: ודאו שמפיקים וצרכנים משתמשים בסריאליזטורים ודה-סריאליזטורים תואמים שמודעים לסכימות האירועים. לדוגמה, בעת שימוש ב-Avro, הסריאליזטור ישתמש בסכימה הרשומה כדי לסריאליז את האירוע, והצרכן ישתמש באותה סכימה (שאוחזרה ממאגר הסכימות) כדי לדה-סריאליז אותו.
• מוסכמות שמות נושאים (Topic Naming Conventions): אמנם לא בטיחות טיפוסים ממשית, שמות נושאים עקביים יכולים לעזור בארגון אירועים ולהבהיר איזה סוג אירועים מצפים בנושא נתון (למשל, orders.v1.OrderPlaced).
• גרסת אירועים (Event Versioning): כאשר סכימות אירועים מתפתחות, מנגנוני בטיחות טיפוסים צריכים לתמוך בגרסאות. זה מאפשר תאימות לאחור וקדימה, ומבטיח שצרכנים ישנים עדיין יכולים לעבד אירועים חדשים (עם טרנספורמציות אפשריות) וצרכנים חדשים יכולים לטפל באירועים ישנים.

דוגמה גלובלית:

שקלו פלטפורמת מסחר אלקטרוני גלובלית. כאשר לקוח מבצע הזמנה בסינגפור, שירות ההזמנות (מפיק) מפרסם אירוע `OrderPlaced`. אירוע זה מסורייליז באמצעות Avro, כשהסכימה רשומה במאגר סכימות מרכזי. מתווכי הודעות כמו Apache Kafka, המבוזרים על פני אזורים מרובים לזמינות גבוהה וזמן אחזור נמוך, מפיצים אירוע זה. שירותים שונים – שירות המלאי באירופה, שירות המשלוחים בצפון אמריקה, ושירות ההתראות באסיה – מנויים לאירועי `OrderPlaced`. כל שירות מאחזר את סכימת `OrderPlaced` ממאגר הסכימות ומשתמש בה כדי לדה-סריאליז ולאמת את האירוע הנכנס, ומבטיח שלמות נתונים ללא קשר למיקומו הגיאוגרפי של הצרכן או למחסנית הטכנולוגית שלו.

2. תבנית מימוש מקורות אירועים (Event Sourcing)

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

יישום בטיחות טיפוסים ב-Event Sourcing:

• יומן אירועים בלתי ניתן לשינוי: הליבה של Event Sourcing היא יומן אירועים שניתן רק להוסיף לו. כל אירוע הוא ישות ממדרגה ראשונה עם סוג ו-payload מוגדרים.
• אכיפת סכימות מחמירה: בדומה ל-Pub/Sub, שימוש בשפות הגדרת סכימות חזקות (Avro, Protobuf) עבור כל האירועים הוא קריטי. יומן האירועים עצמו הופך למקור האמת האולטימטיבי, ושלמותו תלויה באירועים בעלי טיפוסים עקביים.
• אסטרטגיית גרסאות אירועים: ככל שהיישום מתפתח, סביר להניח שאירועים יצטרכו להשתנות. אסטרטגיית גרסאות מוגדרת היטב חיונית. צרכנים (או מודלי קריאה) חייבים להיות מסוגלים לטפל בגרסאות אירועים היסטוריות ואף להגר לגרסאות חדשות יותר.
• מנגנוני הפעלת אירועים מחדש: בעת שחזור מצב או בניית מודלי קריאה חדשים, היכולת להפעיל אירועים מחדש עם בטיחות טיפוסים היא קריטית. זה כרוך בהבטחת שדה-סריאליזציה מפרשת כראוי נתוני אירועים היסטוריים בהתאם לסכימה המקורית שלהם.
• ביקורת (Auditability): הטבע הבלתי ניתן לשינוי של אירועים ב-Event Sourcing מספק יכולת ביקורת מצוינת. בטיחות טיפוסים מבטיחה שתיק הביקורת משמעותי ומדויק.

דוגמה גלובלית:

מוסד פיננסי גלובלי משתמש ב-Event Sourcing לניהול עסקאות בחשבונות. כל הפקדה, משיכה והעברה נרשמת כאירוע בלתי ניתן לשינוי (למשל, `MoneyDeposited`, `MoneyWithdrawn`). אירועים אלו מאוחסנים ביומן מבוזר, ניתן להוספה בלבד, כל אחד בעל טיפוס מדויק עם פרטים כמו מזהה עסקה, סכום, מטבע וחותמת זמן. כאשר קצין תאימות בלונדון צריך לבקר חשבון של לקוח, הוא יכול להפעיל מחדש את כל האירועים הרלוונטיים לאותו חשבון, לשחזר את מצבו המדויק בכל נקודת זמן. בטיחות טיפוסים מבטיחה שתהליך ההפעלה מחדש מדויק ושנתוני הפיננסים המשוחזרים אמינים, ועומדים בתקנות פיננסיות גלובליות מחמירות.

3. תבנית הפרדת אחריות פקודה-שאילתה (CQRS)

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

יישום בטיחות טיפוסים ב-CQRS:

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

דוגמה גלובלית:

חברת לוגיסטיקה בינלאומית משתמשת ב-CQRS לניהול פעילות הצי שלה. צד הפקודה מטפל בבקשות כמו 'DispatchTruck' או 'UpdateDeliveryStatus'. פקודות אלו מעובדות, ולאחר מכן מתפרסמים אירועים כמו `TruckDispatched` או `DeliveryStatusUpdated`. צד השאילתה מנהל מודלי קריאה מותאמים למטרות שונות – אחד עבור לוחות מחוונים למעקב בזמן אמת (נצרכים על ידי צוותי תפעול גלובליים), אחד לניתוח ביצועים היסטורי (בשימוש על ידי הנהלה ברחבי העולם), ואחד לחיוב. אירועי `DeliveryStatusUpdated` עם בטיחות טיפוסים מבטיחים שכל מודלי הקריאה המגוונים הללו מתעדכנים באופן מדויק ועקבי, ומספקים נתונים אמינים לצרכים תפעוליים ואסטרטגיים שונים ביבשות שונות.

4. תבנית Saga

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

יישום בטיחות טיפוסים ב-Sagas:

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

דוגמה גלובלית:

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

כלים וטכנולוגיות ל-EDA עם בטיחות טיפוסים

יישום EDAs עם בטיחות טיפוסים דורש בחירה מושכלת של כלים וטכנולוגיות:

• מתווכי הודעות: Apache Kafka, RabbitMQ, AWS SQS/SNS, Google Cloud Pub/Sub, Azure Service Bus. מתווכים אלו מפשטים תקשורת אסינכרונית. לבטיחות טיפוסים, אינטגרציה עם מאגרי סכימות היא המפתח.
• שפות הגדרת סכימות:
• Avro: קומפקטי, יעיל, ומתאים היטב לסכימות מתפתחות. בשימוש נרחב עם Kafka.
• Protobuf: דומה ל-Avro ביעילותו וביכולותיו לאבולוציית סכימות. פותח על ידי גוגל.
• JSON Schema: אוצר מילים חזק לתיאור מסמכי JSON. מפורט יותר מ-Avro/Protobuf אך מציע תאימות רחבה.
• מאגרי סכימות: Confluent Schema Registry, AWS Glue Schema Registry, Azure Schema Registry. אלו מרכזים את ניהול הסכימות ואוכפים כללי תאימות.
• ספריות סריאליזציה: ספריות המסופקות על ידי Avro, Protobuf, או ספריות JSON ספציפיות לשפה המיועדות לעבודה עם סכימות מוגדרות.
• מסגרות ועזרים (Frameworks and Libraries): מסגרות רבות מציעות תמיכה מובנית בטיפול באירועים עם בטיחות טיפוסים, כגון Akka, Axon Framework, או ספריות ספציפיות במערכות האקולוגיות של .NET, Java, או Node.js המשתלבות עם מאגרי סכימות ומתווכי הודעות.

שיטות מומלצות ליישום EDA גלובלי עם בטיחות טיפוסים

אימוץ EDAs עם בטיחות טיפוסים בקנה מידה גלובלי דורש הקפדה על שיטות מומלצות:

• סטנדרטיזציה של הגדרות אירועים מוקדם: השקיעו זמן בהגדרת סכימות אירועים ברורות וממוגרסות לפני תחילת פיתוח משמעותי. השתמשו במודל אירועים קנוני היכן שניתן.
• ניהול סכימות מרכזי: מאגר סכימות אינו אופציונלי; הוא דרישה להבטחת עקביות טיפוסים בין צוותים ושירותים מגוונים.
• אוטומציה של אימות סכימות: יישמו בדיקות אוטומטיות בצינורות CI/CD כדי להבטיח שהגדרות אירועים חדשות או קוד מפיק/צרכן תואמים את הסכימות הרשומות ואת כללי התאימות.
• אימוץ גרסאות אירועים: תכננו אבולוציית סכימות מההתחלה. השתמשו בטכניקות כמו גרסאות סמנטיות לאירועים והבטיחו שצרכנים יכולים לטפל בגרסאות ישנות יותר בצורה חלקה.
• בחירת פורמט סריאליזציה מתאים: שקלו את הפשרות בין Avro/Protobuf (יעילות, טיפוסיות מחמירה) ל-JSON Schema (קריאות, תמיכה רחבה).
• ניטור והתראות על הפרות סכימה: יישמו ניטור כדי לזהות ולהתריע על כל מקרים של חוסר התאמת סכימות או payloads אירועים לא חוקיים המעובדים.
• תיעוד חוזי אירועים: התייחסו לסכימות אירועים כחוזים רשמיים והבטיחו שהן מתועדות היטב, במיוחד עבור אינטגרציות חיצוניות או בין-צוותיות.
• שקלו השפעות זמן אחזור ברשת והבדלים אזוריים: בעוד בטיחות טיפוסים מטפלת בשלמות הנתונים, ודאו שהתשתית הבסיסית (מתווכי הודעות, מאגרי סכימות) בנויה לטפל בהפצה גלובלית, ציות אזורי ותנאי רשת משתנים.
• הדרכה ושיתוף ידע: ודאו שכל צוותי הפיתוח, ללא קשר למיקומם הגיאוגרפי, מקבלים הדרכה על עקרונות EDA עם בטיחות טיפוסים והכלים שבשימוש.

אתגרים ושיקולים

בעוד שהיתרונות משמעותיים, יישום EDAs עם בטיחות טיפוסים גלובלית אינו חף מאתגרים:

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

סיכום

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

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