სერვისებში თქვენ ჩვეულებრივ ვაპირებთ ძლიერ თანმიმდევრობას საბოლოო თანმიმდევრობისთვის, და ეყრდნობით CQRS და event sourcing ის გამოყენებას, რათა ეს პრაქტიკული და სწორი იყოს.
ცვლილების შემდეგ, რეპლიკები გადამიყვნენ "მალე" რა თქმა უნდა მაშინე კი არა. ბიზნესის უმეტეს ნაკადებისთვის მისაღები (საქონლის რაოდენობა შეიძლება ბოლო გახდეს წამით), ზოგიერთისთვის უმისაღები (ბანკის ბალანსის შემოწმება).
გამიჯნეთ write model ერთი ან მეტი read models -ისგან.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
კითხვები უფრო და გადახაზება დამოუკიდებლად ჩაწერისგან; read model განახლდება მოვლენებიდან, ამიტომ ის საბოლოოდ თანმიმდევრია.
მოახდინეთ მოვლენების თანმიმდევრობა როგორც სიმართის წყარო, არა მხოლოდ მიმდინარე მდგომარეობა. მიმდინარე მდგომარეობა მოვლენების კეცი.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| ტექნიკა | მოგება | ხარჯი |
|---|---|---|
| საბოლოო თანმიმდევრობა | ხელმისაწვდომობა, მასშტაბი | დაძველებული კითხვა, კონფლიქტი |
| CQRS | კითხვა/წერის მასშტაბი | ორი მოდელი, რომელიც სინქრონიზდება |
| Event sourcing | აუდიტი, replay, ისტორია | სქემა/მოვლენის ევოლუცია, სირთულე |
ნუ მიიღებთ event sourcing-ს ყველგან — ეს მძლავრია მაგრამ მძიმე. გამოიყენეთ ის სადაც აუდიტი/ისტორია მართლაც მნიშვნელოვანია.
ელემენტარული სისტემები არ შეიძლება ერთდროულად ჰქონდეთ ძლიერი თანმიმდევრობა, ხელმისაწვდომობა და დანაწევრების ტოლერანტობა, ამიტომ უფროსი დიზაინი გაბნელდება, სად არის საბოლოო თანმიმდევრობა მისაღები.
CQRS და event sourcing-ი გაძლევთ ხელსაწყოებს საბოლოო თანმიმდევრობის სანდო და აუდიტორიული — მაგრამ თითოეული ამატებს რეალურ სირთულეს, ამიტომ განიხილეთ ისინი ქირურგიულად, არა ნაგულელი.