גבולות הקשר ותחום

קונטקסט (באנגלית: Bounded Context) הוא גבול ברור שבו פועלת שפה אוביקיטוטית אחת, מודלים עקביים ואינווריאנטים. בתוך הגבול, המונחים הם חד משמעיים (”Bet”, ”Client”, ”Limit”), ומחוץ להקשר מתקשרים עם חוזים (אירועים/צוותים) ולא מושכים בתוך הזנבות הסמנטיים של אנשים אחרים. "גבולות שנבחרו בחוכמה מפחיתים את הקישוריות, מפשטים את קנה המידה ומאיצים את התפתחות המוצר.

1) מדוע אנו זקוקים לגבולות

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

2) כיצד לזהות הקשר מחובר

1. מאורע סוער: רשום את אירועי התחום ”מה קרה”, ואז את המצוות ”מה אתה מבקש לעשות”, ואז את המצרפים ”המבטיחים את הכלל”.

2. אשכולות שפה: היכן שמילים וחוקים תואמים באופן עקבי - פוטנציאל לפני הספירה. כאשר המילה ”לקוח” פירושה שונה (payer vs player) - יש בבירור הקשרים שונים.

3. מה לא ניתן להפר ומי אחראי? האינווריאנט כפול בתוך האלף-לפני-הספירה שיכול להבטיח זאת.

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

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

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

3) הקשרים טיפוסיים (דוגמה לתחום)

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

4) מפת הקשר: כיצד BCs אינטראקציה

• ספק לקוחות. אחד BC (ספק) מספק אירועים/נתונים, השני (לקוח) מכוון את המודלים שלו.
• קונפורמיסט. הלקוח מקבל את שפת הספק ואת המודל כפי שהוא (למשל. ספר חשבונות רגולטורי).
• שותפות. שני BCs מתפתחים בצורה סינכרונית שפה וחוזים (לרוב פקודה/מפת דרכים).
• קרנל המשותף. תת-שפה/ספרייה נפוצה מינימלית, משולבת; השתמש בזהירות.
• שכבה נגד שחיתות (ACL). שכבת הגנה שמתרגמת את המודלים של אחרים לשפה שלהם.
• שירות מארח פתוח/שפה מפורסמת. פרוטוקולים/מזימות ציבוריות, מבוססות ומתועדות.

תרגול: השתמש ב ־ ACLs ובאירועים אסינכרוניים כברירת מחדל; קונפורמיסט - רק אם המפרנס מכתיב את הסטנדרט, קרנל משותף - באופן מינימלי ומודע.

5) כבול = שפה + מודל + אינווריאנטים + אחסון

• שפה בכל מקום. מילון מונחים עם דוגמאות.
• אגרגטים וחוקרים. מי ”מחזיק” בכללים ובאיזה מבצעים מותר.
• מודל עקביות. חזק/CP עבור כסף, EC/סיבתיות עבור חנויות.
• אחסון ואינדקסים. נבחר עבור פולשים ו ־ SLO.
• חוזי יציאה. אירועים/פקודות, סכימה גרסאות, משלוח SLOs.

בחוץ: אין תלות ישירה של SQL/שולחן. תקשורת - באמצעות חוזה.

6) גבולות ועקביות (PACELC)

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

7) שכבה נגד שחיתות (ACL)

המשימה של ה-ACL היא לא לתת לשפה של מישהו אחר ונתונים מלוכלכים בתוך ה-BC.

Schema Miffing: Outsident Status = Internal 'Ledgrint (סוג = קרדיט, סיבה = PsPSettle).
אימות והעשרה: אימות של אינווריאנטים, נורמליזציה של אזורי זמן, מטבעות.
Versioning: תמיכה בחוזה הנצחי של schema _ version, תאימות לאחור.
idempotence: על ידי ”חיצוני _ id'/” operation _ id'.
תצפית: תגי עקבות "מקור", "schema _ version", "mapping _ id', DLQ עבור מסרים" רעילים ".

8) גבולות ונתונים: בעלות, תחזיות, API

בעלות: מי הבעלים של ה ”אמת”? רק הבעלים משנה את התקליט. שאר לפנה "ס - לקרוא מודלים וקישורים.
תחזיות: טבלאות מוכחשות לקריאות; מתעדכנים מהאירועים.
פקודות (מוטציה אצל הבעלים) ובקשות (תחזיות קריאה). אין עדכונים של נתונים של אנשים אחרים.

9) אבולוציה וגרסאות

אירועים ו API - עם 'schema _ version' ומדיניות תאימות (additive + fallback).
Blue/Green by BC: החוזה החדש 'v2' מתפרסם במקביל ל- 'v1', התנועה מועברת בהדרגה.
נדודים: לשינויים גדולים - הקרנה/שירות חדש, ”מתג שני פאזות” של קריאות.

10) בדיקת גבולות

בחינות חוזה: בדיקת BC תואמת לחוזה שפורסם (מבחני יצרן) ומבין נכון את המבחנים של מישהו אחר (בדיקות צרכנים).
מבוסס-מאפיין: אינווריאנטים של אגרגטים בתוך לפני הספירה (שיווי משקל, גבולות, ייחודיות).
כאוס על אינטגרציה: עיכובים, מחוץ לסדר, שכפולים, סכימה-אבולוציה; נוכחות של DLQ ו רדרייב בטוח.
מבחני NFR: p95/peak load at the border (שרת אירועים/ACL).

11) יכולת תצפית ו ־ SLO לפי גבולות

Metrics: דרך של אירועים/פקודות, "projection _ lag _ ms'," dlq _ rate ", שגיאות מיפוי, p95 API.
איתור: תגיות חובה "bc", "terant _ id'," event _ id', "operation _ id'," schema _ version ".
התראות: מעבר לאג ההקרנה, הגדלת כשלי הפקודה, סכימה ”דש” (schema _ mismatch).

12) רב-דייר ואזורים

"דייר _ id' - במפתחות של כל האירועים והתחזיות על הגבול.

הגינות: Publishing/לשרטט מחדש גבולות לכל דייר כדי לשמור על ”רועש”

תושבות: נתוני לפני הספירה חיים באזור ”בית”; חוצה אזורי - אגרגטים/דיווחים.

13) אנטי דפוסים (וכתוצאה מכך גבול מטושטש)

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

14) דוגמה לקונטורס (מזימה מילולית)

[Wallet/Ledger] <--CP, Leader, Transactions-->
publishes: WalletReserved/Committed v
[Betting] <--CP on bid taking-->
events: BetPlaced/Settled v
[Read Models/Analytics] <--EC projection-->

[Payments] --ACL--> [Wallet/Ledger]
[Provider Integration] --ACL--> [Game/Round]
[Compliance] <-events - [KYC/Identity], -> reports [Reporting]

15) מיני-מדריך לבחירת גבול

1. לגבש אינווריאציות ולקבוע מי יכול להבטיח אותם.
2. תאר את המילון (10-20 מונחים) ודאג שלצוות תהיה אותה הבנה.
3. צייר את מפת ההקשר ואת סוגי היחסים.
4. לפתור את מודל העקביות בתוך ובמפרקים.
5. חוזי עיצוב (אירועים/פקודות) ו-ACL.
6. תוכנית לתצפית (מטריות/איתור/התראות) ו ־ DLQ/redrive.
7. הרץ בדיקות חוזה ותוהו ובוהו לשילוב.
8. תקן את הממשל: מי הבעלים של השפה/תכנית, איך נעשים שינויים.

16) רשימת בדיקות לפני המכירה

[ ] כל לפני הספירה יש אוצר מילים, אגרגטים, ואינווריאנטים.

[ יחסים ] מוגדרים על מפת הקשר וחוזים מתועדים.

[ אינטגרציה ] באמצעות אירועים/פקודות ופקודות אזרחיות, ללא תלות ישירה ב-SQL.

[ ] פקודה/אידמפוטנטיות אירוע; יש תיבת דואר אלקטרוני ו-DLQ.

[ ] מודל עקביות (intra/inter BC) קבוע ונבדק.

[ ] סכימה ואסטרטגיית תאימות (v1/v2).

[ ] לאג/שגיאה/מדדי ביצועים והתראות מוגדרים.

[ ] מדיניות רב-שכבתית ותושבות נתונים נאכפים.

[ ] מחזות הפעלה: סכימה-אי התאמה, מחדש, לבנות מחדש תחזיות.

17) מתכונים מהירים

כסף ומגבלות: נפרדים לפני הספירה עם CP ועסקאות, API מצווה רק, אירועים כתוצאת האמת לקריאות.
הזנות/ספריות: לפני הספירה עם EC, תחזיות ומטמון, ”רעננות” מפורשת.
אינטגרציה עם ספקים חיצוניים: תמיד באמצעות ACL, אירועים/פקודות, סכימה.
צמיחה קבוצתית: 1 לפנה "ס היא קבוצה אחת, לקבוצה יש" בעל שפה "ו" שומר של אינווריאנטים ".
חידוש מונולית: חוזים ואגודות אזרחיות קודם, ואז הפרדה פיזית.

סיכום

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