Bounded Context და დომენის საზღვრები

Bounded Context (BC) არის მკაფიო საზღვარი, რომლის შიგნით არის ერთი Ubiquitous ენა, შეთანხმებული მოდელები და ინვარიანტები. საზღვრის შიგნით, ტერმინები ერთმნიშვნელოვანია („შტაბი“, „კლიენტი“, „ლიმიტი“), ხოლო კონტექსტი კომუნიკაბელურია კონტრაქტებით (მოვლენები/გუნდები) და არ იჭერს სხვა ადამიანების სემანტიკურ „კუდებს“ შიგნით. კომპეტენტურად შერჩეული საზღვრები ამცირებს კავშირს, ამარტივებს მასშტაბს და აჩქარებს პროდუქტის ევოლუციას.

1) რატომ გვჭირდება საზღვრები?

შემეცნებითი დატვირთვის შემცირება. გუნდი მუშაობს ერთ მოდელთან და ერთ ენასთან და არა „ყველა ბიზნესთან ერთდროულად“.
ინვარიანტების იზოლაცია. კრიტიკული წესები (ბალანსი 0, ლოგინის უნიკალურობა) ერთ ადგილზე ცხოვრობენ და დაცულია აგრეგატებით.
ცვლილების მენეჯმენტი. BC- ს შიგნით სქემის/წესების ევოლუცია არ არღვევს მეზობელს - არსებობს აშკარა კონტრაქტები.
პროდუქტიულობა და საიმედოობა. BC- ს შიგნით შეგიძლიათ აირჩიოთ შესაფერისი კოორდინაციის და შენახვის მოდელი; გარედან - ასინქრონული პროექციები.

2) როგორ დავადგინოთ Bounded Context

1. Event Storming: ჩამოწერეთ აფეთქების ღუმელის მოვლენები „რა მოხდა“, შემდეგ ბრძანებები „რა ვთხოვოთ“, შემდეგ აგრეგატები „ვინ გარანტიას უწევს წესს“.

2. ენის მტევანი: სადაც სიტყვები და წესები სტაბილურად ემთხვევა - პოტენციური BC. სადაც სიტყვა „კლიენტი“ ნიშნავს განსხვავებულ (გადამხდელს) - აშკარად განსხვავებული კონტექსტები არსებობს.

3. ინვარიანტები და ownership: რა არ შეიძლება დაირღვეს და ვინ პასუხობს? ინვარიანტი არის BC- ს შიგნით, რომელსაც შეუძლია ამის გარანტია.

4. ღირებულების ნაკადი: დაჯგუფეთ ნაბიჯები, რომლებიც ხშირად იცვლება ერთად - ესენი არიან კანდიდატები ერთი BC- სთვის.

5. Org სტრუქტურა: თუ ცალკეული KPI გუნდი ერთ ნაწილს აკეთებს, ეს ალბათ ცალკე BC (მაგრამ არა პირიქით: ორგანიზაციული სტრუქტურა არ უნდა ბრმად კარნახობდეს მოდელს).

• ტერმინებზე დავა („კურსი“, „ბილეთი“, „რაუნდი“ - სხვადასხვა მნიშვნელობა).
• ყველაზე ცხელი ინვარიანტი „მიედინება“ სერვისებით.
• სხვადასხვა SLO და ცვლილებების ტემპი.
• „ორმაგი რწმენა“ მოდულებს შორის ატომურობისთვის.

3) ტიპიური კონტექსტები (საგნის არეალის მაგალითი)

პირადობა/KYC - რეგისტრაცია, გადამოწმების დონე, შეზღუდვების სტატუსი.
Wallet/Ledger - ბალანსები, გაყვანილობა, რეზერვები, ვალუტები.
Betting/Orders - ტექნიკა, ციტატები, გაანგარიშება.
Game/Round - რაუნდის სასიცოცხლო ციკლი, შედეგები.
Bonus/Promo - დარიცხვები, ვაგნერი, კონვერტაცია.
Payments - ანაბრები/დასკვნები, გადახდის კარიბჭეების სტატუსები.
Compliance/Reporting - მოხსენებები, აუდიტი, მარეგულირებელი ფანჯრები.
Catalog/Provider Integration - თამაშები, ვერსიები, პროვაიდერების სტატუსები.
Analytics/Read Models - პროექციები და მატერიალიზებული წარმოდგენები.

4) Context Map: როგორ ურთიერთქმედებენ BC

• Customer–Supplier. ერთი BC (Supplier) აწვდის მოვლენებს/მონაცემებს, მეორე (Customer) აუმჯობესებს თავის მოდელებს.
• Conformist. Customer იღებს ენასა და Supplier მოდელს, როგორც არის (მაგალითად, მარეგულირებელი რეესტრი).
• Partnership. ორი BC სინქრონულად ეყრდნობა ენასა და კონტრაქტებს (ხშირად ერთი ბრძანება/roadmap).
• Shared Kernel. საერთო მინიმალური აღმართი/ბიბლიოთეკა ერთად არის ვერსირებული; სიფრთხილით გამოყენება.
• Anti-Corruption Layer (ACL). დამცავი ფენა, რომელიც თარგმნის სხვა ადამიანების მოდელებს საკუთარ ენაზე.
• Open Host Service / Published Language. საჯარო ოქმები/სქემები, ვერსირებული და დოკუმენტირებული.

პრაქტიკა: გამოიყენეთ ACL და ასინქრონული მოვლენები; Conformist - მხოლოდ იმ შემთხვევაში, თუ პროვაიდერი კარნახობს სტანდარტს, Shared Kernel - მინიმალური და შეგნებული.

5) საზღვარი = ენა + მოდელი + ინვარიანტები + საცავი

• Ubiquitous Language. ტერმინების ლექსიკონი მაგალითებით.
• დანაყოფები და ინვარიანტები. ვინ „ფლობს“ წესებს და რა ოპერაციებია ნებადართული.
• კოორდინაციის მოდელი. Strong/CP ფულისთვის, EC/causal ფანჯრებისთვის.
• შენახვა და ინდექსები. შერჩეულია ინვარიანტები და SLO.
• გასასვლელი ხელშეკრულებები. მოვლენები/ბრძანებები, სქემების ვერსიები, SLO მიწოდება.

გარეთ: არ არსებობს პირდაპირი SQL/ფირფიტის დამოკიდებულება. კომუნიკაცია - ხელშეკრულების საშუალებით.

6) საზღვრები და კოორდინაცია (PACELC)

შიგნით BC: შეარჩიეთ მოდელი ინვარიანტებისთვის (Wallet - Strong, Betting - Strong მისაღებში).
BC- ს შორის: ყველაზე ხშირად მოვლენა მოვლენებისა და პროექციის საშუალებით. თუ საჭიროა სინქრონიზებული შემოწმება, აშკარა გუნდი, რომელსაც აქვს ვადა და მიუწვდომლობა (არ არის „დამალული“ REST ზარები).

7) ანტიკორუფციული ფენა (ACL)

ACL- ის ამოცანა: არ დაუშვათ სხვისი ენა და „ბინძური“ მონაცემები BC- ს შიგნით.

Mapping სქემები: გარეგანი 'PayStatus = SETTLED' - შიდა 'LedgerEntry (ტიპი = კრედიტი, reason = PsPSettle) ".
სავალდებულო და გამდიდრება: ინვარიანტების შემოწმება, ტაიმსონის ნორმალიზაცია, ვალუტები.
ვერსია: გარე ხელშეკრულების 'schema _ version' მხარდაჭერა, საპირისპირო თავსებადობა.
Idempotenty: 'external _ id '/' operation _ id'.
დაკვირვება: trace ჭდეები 'source', 'schema _ version', 'mapping _ id', DLQ „შხამიანი“ შეტყობინებებისთვის.

8) საზღვრები და მონაცემები: საკუთრება, პროექცია, API

Ownership: ვინ ფლობს „ჭეშმარიტებას“? მხოლოდ მეპატრონე ცვლის ჩანაწერს. დანარჩენი BC არის read მოდელები და ბმულები.
პროგნოზები: წაკითხული დენორმალიზებული ცხრილი; განახლებულია მოვლენებიდან.
API: გუნდები (მუტაცია მფლობელთან) და მოთხოვნები (წაიკითხეთ პროექციები). სხვა ადამიანების მონაცემების „მეშვეობით“.

9) ევოლუცია და ვერსიები

მოვლენები და API - 'schema _ version' და თავსებადობის პოლიტიკა (additive + fallback).
Blue/Green on BC: ახალი კონტრაქტი 'v2' ქვეყნდება პარალელურად 'v1', ტრეფიკი თანდათანობით გადადის.
მიგრაცია: სერიოზული ცვლილებებისთვის - ახალი პროექცია/სერვისი, კითხვების „ორფაზიანი სვიტრი“.

10) საზღვრების ტესტირება

Contract tests: შემოწმება, რომ BC აკმაყოფილებს გამოქვეყნებულ კონტრაქტს (productions) და სწორად ესმის სხვისი (consumer tests).
Property-based: BC- ს შიგნით აგრეგატების ინვარიანტები (ბალანსი, ლიმიტები, უნიკალურობა).
ქაოსი ინტეგრაციებში: შეფერხებები, out-of-order, დუბლიკატები, schema-evolution; DLQ და უსაფრთხო რადარის არსებობა.
NFR ტესტები: საზღვარზე r95/პიკის დატვირთვა (ღონისძიების სერვერი/ACL).

11) საზღვრებში დაკვირვება და SLO

მეტრიკა: throughput მოვლენები/ბრძანებები, 'projection _ lag _ ms', 'dlq _ rate', mapping შეცდომები, p95 API.
ტრეისი: სავალდებულო ჭდეები 'bc', 'tenant _ id', 'event _ id', 'operation _ id', 'schema _ version'.
ალერტები: პროექციების ჭარბი რაოდენობა, ბრძანებების წარუმატებლობის ზრდა, სქემის „flap“ (მრავალი 'schema _ mismatch').

12) მულტფილმები და რეგიონები

'tenant _ id' - საზღვარზე ყველა მოვლენისა და პროექციის გასაღებებში.
Fairness: პუბლიკაციების შეზღუდვები/რედაქცია per tenant ისე, რომ „ხმაურიანი“ არ დაარღვიოს მეზობლების SLO.
Residency: BC მონაცემები ცხოვრობს „საშინაო“ რეგიონში; ჯვარედინი რეგიონალური - აგრეგატები/მოხსენებები.

13) ანტი-ნიმუშები (რა იწვევს ბუნდოვან საზღვარს)

გიგანტური „core-service“. ყველა ერთ ადგილზე - ბრძოლა გარიგებისთვის, გრძელი გამოშვებები, დაბალი ავტონომია.
ფირფიტის ინტეგრაცია. სწორი SELECT სხვის ცხრილებში არის მყიფე და coupling სქემის მიხედვით.
Dual-write. ამავე დროს, დაწერეთ ორი BC „მოხერხებულობისთვის“ - შეუსაბამობები და ინვარიანტების დივერსია.
ნაგულისხმევი Conformist. „მათ მიიღეს სხვისი მოდელი, როგორც არის“, სხვისი მნიშვნელობების გაჟონვა, ევოლუციის შეუძლებლობა.
ფარული სინქრონული გამოწვევები. REST ზარები „სადღაც შიგნით“ აშკარა კონტრაქტის და ვადაგადაცილების გარეშე, ხელმისაწვდომობის მოულოდნელი დამოკიდებულებაა.

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. Context Map და ურთიერთობების ტიპები.
4. მოაგვარეთ კოორდინაციის მოდელი შიგნით და სახსრებში.
5. შეიმუშავეთ კონტრაქტები (მოვლენები/გუნდები) და ACL.
6. დაკვირვება (მეტრიკა/ტრეისი/ალერტები) და DLQ/redrive.
7. ჩაატარეთ კონტრაქტები-tests და „ქარიშხალი“ ინტეგრაციისთვის.
8. ჩაწერეთ მთავრობა: ვინც საუბრობს ენაზე/სქემაზე, როგორ ხდება ცვლილებები.

16) ჩეკის სია გაყიდვამდე

• თითოეულ BC- ს აქვს ლექსიკონი, აგრეგატები და ინვარიანტები.
• განსაზღვრულია ურთიერთობები Context Map- ზე და დოკუმენტირებულია ხელშეკრულებები.
• ინტეგრაცია მოვლენათა/ბრძანებების და ACL- ის მეშვეობით, არ არსებობს პირდაპირი SQL დამოკიდებულება.
• გუნდების/მოვლენების იდენტურობა; აქ არის outbox/inbox და DLQ.
• კოორდინაციის მოდელი (შიგნით/BC- ს შორის) დაფიქსირდა და შემოწმდა.
• სქემების ვერსია და თავსებადობის სტრატეგია (v1/v2).
• lage/შეცდომების/შესრულების მეტრიკა და ალერტები მორგებულია.
• დაიცვა მრავალ ტენანტობისა და მონაცემთა გამოკითხვის პოლიტიკოსები.
• ოპერაციული ფლეიბუკები: schema-mismatch, redrive, rebuild პროგნოზები.

17) სწრაფი რეცეპტები

ფული და ლიმიტები: ცალკეული BC CP- ით და გარიგებებით, API მხოლოდ გუნდებით, მოვლენები, როგორც ჭეშმარიტების შედეგი კითხვისთვის.
ფიდები/კატალოგები: BC EC, პროექციები და ქეში, აშკარა 'freshness'.
გარე პროვაიდერთან ინტეგრაცია: ყოველთვის ACL, მოვლენები/ბრძანებები, სქემების ვერსიები.
გუნდის ზრდა: ერთი BC არის ერთი გუნდი, გუნდს აქვს „ენის მფლობელი“ და „ინვარიანტის მცველი“.
მონოლითის რეფაქტორი: ჯერ კონტრაქტები და ACL, შემდეგ ფიზიკური დაყოფა.

დასკვნა

Bounded Context არ არის მხოლოდ დიაგრამა, არამედ სამუშაო ხელშეკრულება ენის, წესებისა და ევოლუციის შესახებ. მკაფიო საზღვრები ამცირებს დაკავშირებას, აჩქარებს ცვლილებებს და სისტემას პროგნოზირებს ექსპლუატაციაში. გაიზიარეთ მნიშვნელობებითა და ინვარიანტებით, დაიცავით ACL საზღვრები და კონტრაქტები, გაზომეთ ყველა მეტრი - და თქვენი არქიტექტურა დარჩება მოქნილი და საიმედო, თუნდაც დომენისა და გუნდის სწრაფი ზრდით.