Vzor Event Sourcing

Místo uložení pouze aktuálního stavu dat v relační databázi uložte celou řadu akcí provedených u objektu v úložišti jen pro připojení. Úložiště funguje jako systém záznamu, který můžete použít k materializaci objektů domény. Tento přístup může zlepšit auditovatelnost a výkon zápisu ve složitých systémech.

Důležité

Event Sourcing je složitý vzor, který představuje významné kompromisy. Mění způsob ukládání dat, zpracování souběžnosti, vývoj schémat a stav dotazů. Migrace do nebo z řešení event sourcing je nákladná a po přijetí tohoto vzoru omezuje budoucí rozhodnutí o návrhu v částech systému, které ho používají. Osvojte si sourcing událostí, když jeho výhody, jako je auditovatelnost a historická rekonstrukce, odůvodňují složitost vzoru. U většiny systémů a většiny částí systému stačí tradiční správa dat.

Kontext a problém

Většina aplikací pracuje s daty. Aplikace obvykle ukládá nejnovější stav dat do relační databáze a podle potřeby vkládá nebo aktualizuje data. Například v tradičním modelu vytvoření, čtení, aktualizace a odstranění (CRUD) aplikace čte data z úložiště, upraví je a aktualizuje aktuální stav dat novými hodnotami, obvykle pomocí transakcí, které data zamknou.

Přístup CRUD je pro většinu scénářů jednoduchý a rychlý. V systémech s vysokým zatížením ale tento přístup představuje výzvy:

• Kolize zápisu: Vzhledem k tomu, že aktualizace vyžadují cykly čtení a úpravy zápisu s uzamčením na úrovni řádků, souběžné zápisy do stejné entity snižují výkon a stávají se kritickým bodem při zatížení.

• Auditovatelnost: Systémy CRUD ukládají pouze nejnovější stav dat. Pokud neimplementujete mechanismus auditování, který zaznamenává podrobnosti jednotlivých operací v samostatném protokolu, ztratíte historii dat.

Řešení

Vzor Event Sourcing definuje přístup ke zpracování operací s daty, které jsou poháněny posloupností událostí. Každá událost se zaznamená v úložišti jen pro připojení. Kód aplikace vyvolá události, které popisují každou akci prováděnou u objektu. Obvykle odesílá události do fronty, kde samostatný proces, zpracovatel událostí, poslouchá na frontě a ukládá události do úložiště událostí. Každá událost představuje logickou změnu objektu, například AddedItemToOrder nebo OrderCanceled.

Události se uchovávají v úložišti událostí, které slouží jako systém záznamu nebo autoritativní zdroj dat o aktuálním stavu dat. Dodatečné obslužné rutiny pro události můžou naslouchat konkrétním událostem a podle potřeby provádět akce. Spotřebitelé mohou například zahájit úlohy, které aplikují operace na události do jiných systémů, nebo podniknout jiné související kroky nutné k dokončení operace. Kód aplikace, který generuje události, je oddělený od systémů, které se přihlásí k odběru událostí.

Každá entita ve zdrojovém systému událostí má svůj vlastní eventstream, což je seřazená posloupnost událostí, které zaznamenávají každou změnu dané entity. V každém okamžiku můžou aplikace číst historii událostí. Aplikace odvozují aktuální stav entity tak, že přehrají všechny události ve svém streamu. Tento proces se označuje jako rehydratace. Může k němu dojít na vyžádání, když aplikace zpracuje požadavek.

Aplikace obvykle implementují materializovaná zobrazení , protože je nákladné číst a přehrávat události. Materializovaná zobrazení jsou projekce jen pro čtení úložiště událostí, které jsou optimalizované pro dotazování. Systém může například udržovat materializované zobrazení všech objednávek zákazníků, které používá k naplnění uživatelského rozhraní. Když aplikace přidá nové objednávky, přidá nebo odebere položky v objednávce nebo přidá expediční informace, aplikace vyvolá události a obslužná rutina aktualizuje materializované zobrazení.

Následující diagram znázorňuje přehled tohoto modelu v kombinaci se vzorem CQRS (Command Query Responsibility Segregation). Prezentační vrstva čte z samostatného úložiště jen pro čtení a zapisuje příkazy do obslužných rutin příkazů. Obslužné rutiny příkazů načtou tok událostí entity z úložiště událostí, provedou obchodní logiku a vloží nové události do fronty. Obslužné rutiny událostí využívají události z fronty a zapisují události do úložiště událostí, aktualizují úložiště jen pro čtení nebo se integrují s externími systémy.

V horní části diagramu představuje pole prezentační vrstvu. Šipka označená v pravém horním rohu čte body z prezentační vrstvy do pole označeného obchodním objektem, který odkazuje na úložiště jen pro čtení. Šipka označená zapisuje body z prezentační vrstvy do pole vlevo, které obsahuje obslužné rutiny příkazů a obchodní objekty. Z tohoto pole vede šipka označená "získat události košíku" do úložiště událostí. Další šipka ukazuje z okna obslužných rutin příkazů do pole v dolní části označené jako fronta nebo téma, které obsahuje sedm ikon obálek. Vedle této šipky ikony obálek představují události, jako je košík vytvořený, položka 1 přidaná, položka 2 přidána, položka 1 odebrána a přidané informace o expedici. Tři šipky vedou z fronty nebo tématického pole na samostatné obslužné procesy. Obslužná rutina události úplně vlevo zapisuje události do úložiště událostí. Obslužná rutina prostřední události aktualizuje úložiště jen pro čtení. Obslužná rutina událostí úplně vpravo se integruje s externími systémy.

Stáhněte si soubor aplikace Visio s touto architekturou.

Workflow

Následující pracovní postup odpovídá předchozímu diagramu:

1. Prezentační vrstva volá objekt, který čte z úložiště jen pro čtení. Použije vrácená data k naplnění uživatelského rozhraní.

2. Prezentační vrstva volá obslužné rutiny příkazů k provádění akcí, jako je vytvoření košíku nebo přidání položky do košíku.

3. Obslužná rutina příkazu načte entitu načtením jejího eventstreamu z úložiště událostí. Může například načíst všechny události košíku. Přehraje tyto události vůči entitě, aby rekonstruovala svůj aktuální stav předtím, než dojde k nové akci.

4. Obchodní logika se spustí a události jsou vyvolány. Ve většině implementací se události oddělují do fronty nebo tématu, aby se oddělily producenti událostí a příjemci událostí.

5. Obslužné rutiny událostí naslouchají konkrétním událostem a pro tuto obslužnou rutinu přijmou příslušnou akci. V tomto příkladu obslužné rutiny událostí provádějí následující akce:

   1. Zápis událostí do úložiště událostí

   2. Aktualizace úložiště jen pro čtení optimalizovaného pro dotazy

   3. Integrace s externími systémy

Výhody vzorů

Model Event Sourcing má následující výhody:

• Události jsou neměnné a můžete je uložit pomocí operace typu append-only. Uživatelské rozhraní, pracovní postup nebo proces, který spouští událost, může pokračovat a úlohy, které zpracovávají události, se můžou spouštět na pozadí. Propustnost zápisu se výrazně zlepšuje, zejména pro vrstvu prezentace, protože zápisy pouze připojováním se vyhýbají kolizím uzamčení na úrovni řádku, které vytvářejí systémy s aktualizací na místě.

• Události jsou jednoduché objekty, které popisují akci, která se vyskytuje spolu s přidruženými daty potřebnými k popisu akce, kterou událost představuje. Události neaktualizují úložiště dat přímo. Obslužné rutiny událostí sčítají a zpracovávají zaznamenané události, když je k dispozici obslužná rutina a systém dokáže zpracovat zatížení. Události vám pomůžou zjednodušit implementaci a správu.

• Expertovi na doménu budou události obvykle dávat smysl, ale neshoda v oblasti objektově-relační impedance může zhoršit srozumitelnost u složitých databázových tabulek. Tabulky jsou umělé konstrukce, které představují aktuální stav systému, nikoli události, ke kterým dochází.

• Model Event Sourcing může pomoct předcházet konfliktům vyplývajícím ze souběžných aktualizací, protože se eliminuje nutnost přímo aktualizovat objekty v úložišti dat. Obslužné rutiny příkazů rehydratují entitu z svého eventstreamu a vynucují podniková pravidla před připojením nových událostí, takže dvě obslužné rutiny, které načítají stejnou entitu současně, mohou jednat ve stejném stavu.

  Například každý operátor vidí pět zbývajících míst a oba operátoři můžou přijmout rezervaci. Úložiště událostí tento scénář řeší pomocí optimistického řízení souběžnosti a odmítne připojení, pokud se datový proud od čtení změnil. Po zamítnutí obslužná rutina entitu znovu načte, znovu vyhodnocuje a opakuje.

• Úložiště událostí pouze pro připojování poskytuje auditní záznam, který můžou aplikace použít k monitorování akcí provedených v datovém úložišti. Aktuální stav může kdykoli znovu vygenerovat jako materializovaná zobrazení nebo projekce tím, že události přehraje a může pomoct testovat a ladit systém.

  Požadavek na použití kompenzačních událostí ke zrušení změn může poskytnout historii obrácených změn. Pokud model ukládá pouze aktuální stav, tato historie neexistuje. Seznam událostí můžete použít také k analýze výkonu aplikace, zjišťování trendů chování uživatelů a získání dalších užitečných obchodních informací.

• Obslužné rutiny příkazů vyvolávají události a úlohy provádějí operace v reakci na tyto události. Toto oddělení úloh od události zajišťuje flexibilitu a rozšiřitelnost. Úkoly vědí o typu události a datech události, ale ne o operaci, která událost aktivuje.

  Každá událost může zpracovávat několik úloh, takže se může snadno integrovat s jinými službami a systémy, které naslouchají pouze novým událostem, které úložiště událostí vyvolává. Události event sourcing jsou ale obvykle nízké úrovně a místo toho může být nutné vygenerovat konkrétní integrační události.

Návod

Model Event Sourcing se běžně kombinuje se vzorem CQRS provedením úloh správy dat v reakci na události a materializací zobrazení z uložených událostí. Pomocí této kombinace můžete nezávisle škálovat čtení a zápisy, protože ingestování událostí pouze pro přidávání a projekce optimalizované pro dotazy fungují samostatně.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

• Návrh událostí: Navrhujte události tak, aby zachycovaly obchodní záměr za každou změnou a zároveň výsledný stav. Například v systému rezervace licencí je událost, která zaznamenává, že byly rezervovány dvě místa , cennější než událost, která zaznamenává zbývající místa změněná na 42. První událost vám řekne, co se stalo. Druhá událost vás informuje pouze o výsledném stavu. Události zaměřené na stav systému snižují úložiště událostí na protokol změn, který nemá žádný praktický význam. Události zaměřené na záměr poskytují podrobnější projekce, smysluplné záznamy auditu a flexibilitu při vytváření nových modelů čtení z historických událostí bez nutnosti měnit prostředí zápisu.

• Konečná konzistence: Systém je nakonec konzistentní pouze v případech, kdy vytváří materializovaná zobrazení nebo generuje projekce dat přehráváním událostí. Mezi tím, kdy aplikace zpracovává požadavek a přidává události do úložiště událostí, kdy události publikují a kdy příjemci události zpracovávají, existuje zpoždění. Během této doby můžou do úložiště událostí přijít nové události, které popisují další změny entit. Ujistěte se, že vaši zákazníci chápou, že data jsou nakonec konzistentní a že je systém navržený tak, aby v těchto scénářích odpovídal konečné konzistenci.

• Ukládání verzí událostí: Úložiště událostí je trvalým zdrojem informací, takže byste data události nikdy neměli aktualizovat. Jediným způsobem, jak aktualizovat entitu nebo vrátit zpět změnu, je přidat do úložiště událostí kompenzační událost. Kompenzační událost je nová událost, která obrátí nebo opraví účinek předchozí události. Například událost ReservationCanceled kompenzuje předchozí událost SeatsReserved. Původní událost zůstane ve streamu a korekční událost zaznamenává, že byla zrušena.

  Tato neměnnost také znamená, že pokud chyba způsobí nesprávné události, tyto události se zachovají v úložišti. Oprava chyby v kódu aplikace neopravuje historické události, takže můžete také potřebovat kompenzační události nebo upcastery pro zpracování chybných dat během přehrání. Pokud se schéma (místo dat) trvalých událostí musí změnit, třeba během migrace, může být obtížné kombinovat existující události v úložišti s novou verzí.

  Můžete použít následující strategie jednotlivě nebo v kombinaci:

  • Tolerantní deserializace: Navrhnout, aby příjemci událostí ignorovali neznámá pole a používali výchozí hodnoty pro chybějící pole. Tento přístup zpracovává aditivní, nezpůsobující rozpad změny, jako je přidání volitelného pole, aniž by bylo nutné provádět úpravu uložených událostí.

  • Správa verzí událostí: Do každé události zahrňte identifikátor verze, a to buď jako metadata v obálce události, nebo jako součást názvu typu události. Uživatelé používají verzi k výběru vhodné logiky zpracování.

  • Přesílání: Registrace transformačních funkcí, které během deserializace převádějí starší schémata událostí na aktuální schéma Můžete zřetězit upcastery tak, aby kód aplikace potřeboval zpracovat pouze nejnovější verzi. Uložené události zůstávají nezměněné, což zachovává neměnnost.

  • Místní migrace: Přepište historické události do nového schématu přímo v úložišti událostí. Tento přístup porušuje neměnnost a měl by být posledním řešením, protože podkopává záznam auditu.

• Řazení událostí: Vícevláknové aplikace a více instancí aplikací můžou ukládat události v úložišti událostí. Konzistence událostí v úložišti událostí a pořadí událostí, které ovlivňují aktuální stav konkrétní entity, jsou zásadní. Přidání časového razítka do každé události vám může pomoct vyhnout se problémům. Dalším běžným postupem je přidání poznámek ke každé události, která je výsledkem požadavku s přírůstkovým identifikátorem. Pokud se dvě akce současně pokusí o přidání událostí pro stejnou entitu, úložiště událostí může zamítnout událost, která odpovídá existujícímu identifikátoru entity a identifikátoru události.

• Dotazování na události: Neexistuje žádný standardní přístup ani existující mechanismy, jako jsou dotazy SQL, pro čtení událostí pro získání informací. Jedinými daty, která můžete extrahovat, je datový proud událostí pomocí identifikátoru události jako kritérií. ID události se obvykle mapuje k jednotlivým entitám. Aktuální stav entity můžete určit pouze tak, že přehrajete všechny události, které se k ní vztahují, proti původnímu stavu dané entity.

• Možnosti úložiště událostí: Úložiště událostí může být účelově sestavená databáze navržená pro událostní toky pouze pro přidávání nebo obecná relační či dokumentová databáze s tabulkou pouze pro přidávání.

  • Účelově sestavená úložiště událostí poskytují integrovanou podporu pro úlohy, jako je čtení streamu podle entity, optimistické souběžnosti a snímků.

  • Relační databáze jsou známé a široce dostupné, ale vyžadují, abyste tyto chování vytvořili sami.

  Vzhledem k tomu, že každá entita má vlastní nezávislý eventstream, ukládá událost oddíl přirozeně podle ID entity, což v případě potřeby zjednodušuje horizontální škálování nebo horizontální dělení.

  Důležité

  Nezaměňujte úložiště událostí s zprostředkovatelem zpráv eventstream. Zprostředkovatelé zpráv, jako je Apache Kafka, obvykle nemají dotazy na datový proud jednotlivých entit a optimistickou souběžnost. Fungují stejně jako distribuční vrstva pro vysílnutí událostí pro projekce a externí uživatele, ale nejsou náhradou za úložiště událostí.

• Opětovné vytvoření stavu entity: Délka každého streamu událostí ovlivňuje způsob správy a aktualizace systému. Pokud jsou datové proudy velké, znovu přehrát každou událost pro obnovení stavu entity se stane nákladným jak z hlediska času, tak i výpočetní síly. Pokud chcete tyto náklady zmírnit, vytvořte snímky v konkrétních intervalech, například každé N události. Snímek je serializovaná reprezentace stavu entity v určitém bodě v jeho eventstreamu. Pokud chcete entitu rehydratovat, načtěte nejnovější snímek a přehrajte pouze události, které nastaly po něm, namísto přehrávání celého datového proudu od začátku. Když zvolíte frekvenci snímků, vyvažte náklady na úložiště snímků s časem ušetřeným během obnovy.

  Poznámka:

  Snímky představují optimalizaci, nikoli náhradu za stream událostí. Eventstream zůstává zdrojem pravdy a snímky z něj můžete kdykoli znovu vygenerovat.

• Zpracování konfliktů: Optimistické řízení souběžnosti brání konfliktní zápisy do stejného streamu událostí, ale aplikace musí stále zpracovávat konflikty, které zahrnují více entit. Například událost, která indikuje snížení skladových zásob, může přijít do úložiště dat, zatímco zákazník zadá objednávku dané položky. Navrhni systém tak, aby tyto situace vyřešil, například tím, že poskytne radu zákazníkovi nebo vytvoří nedodělek.

• Požadavky na idempotenci: Doručování událostí příjemcům je obvykle alespoň jednou, takže příjemci mohou obdržet stejnou událost více než jednou. Obslužné rutiny událostí musí být idempotentní, takže zpracování duplicitní události nezmění výsledek. Pokud například více instancí procesu pro zpracování událostí rezervace míst zachovává stav dostupných míst, musí opakované události rezervace vést pouze k jednomu snížení počtu. Bez idempotence se projekce odchylují od streamu událostí a vedlejších účinků, jako jsou platby nebo oznámení, aktivují více než jednou. Sledujte poslední zpracovávané pořadové číslo události pro každého příjemce a přeskočte duplicity nebo změny stavu návrhu, které jsou ze své podstaty bezpečné k opakování.

• Kruhová logika: Mějte na paměti scénáře, ve kterých zpracování jedné události vyžaduje vytvoření jedné nebo více nových událostí. Výsledkem této sekvence může být nekonečná smyčka.

• Testování: Konkrétní styl testování nejlépe vyhovuje systémům založeným na událostech. Nastavte minulé události, vystavte příkaz a vygenerujte nové události. Tento přístup typu `given-when-then` testuje obchodní logiku bez databází, front nebo projekcí. Ale potřebujete také integrační testy pro projekce, chování idempotence a evoluční cesty schématu, což zvyšuje rozsah testování v porovnání se systémy CRUD.

• Osobní údaje a dodržování právních předpisů: Neměnná povaha úložiště událostí je v konfliktu s předpisy o ochraně osobních údajů, které vyžadují odstranění osobních údajů, jako je právo na zapomenuté zákony. Navrhněte řešení, které od začátku zohledňuje napětí spojené s přímým odstraňováním událostí, které narušuje integritu datového proudu.

  • Běžným přístupem je ukládání osobních údajů mimo úložiště událostí a jejich odkazování na základě identifikátoru v událostech. Tento přístup umožňuje nezávislé odstranění, aniž by to ovlivnilo stream událostí.

  • Pokud nemůžete oddělit osobní údaje od událostí, použijte crypto-shredding. Šifrujte osobní údaje v událostech pomocí klíče na jednotlivé subjekty. Odstraňte klíč pro vykreslení dat, která jsou neobnovitelná, a přitom ponechte strukturu událostí nedotčenou. Tento přístup zvyšuje režii šifrování při každém čtení a zápisu a vyžaduje robustní správu klíčů.

Kdy použít tento vzor

Tento model použijte v těchto případech:

• V datech chcete zachytit záměr, účel nebo důvod. Změny entity zákazníka můžete například zaznamenat jako řadu konkrétních typů událostí, jako je Přesunuto domů, Uzavřený účet nebo Zemřelý.

• Je nutné minimalizovat nebo úplně zabránit konfliktům aktualizací dat.

• Chcete zaznamenávat události, ke kterým dochází, abyste je přehráli za účelem obnovení stavu systému, vrácení změn zpět nebo uchování historie a protokolu auditování. Pokud se například úkol skládá z několika kroků, budete možná muset spustit akce, aby se aktualizace vrátily, a pak znovu přehrát některé kroky, aby se data vrátila do konzistentního stavu.

• Aplikace už používá události jako přirozenou funkci své operace a event sourcing vyžaduje málo dalšího úsilí o vývoj nebo implementaci.

• Je potřeba oddělit proces zadávání nebo aktualizace dat od úloh potřebných k použití těchto akcí. Tato změna může zlepšit výkon uživatelského rozhraní nebo distribuovat události jiným nasloucháčům, kteří reagují na jejich výskyt. Můžete například integrovat mzdový systém s webem pro odeslání výdajů. Web i mzdový systém spotřebovávají události, které úložiště událostí vyvolává v reakci na data aktualizovaná na webu.

• Chcete flexibilitu změnit formát materializovaných modelů a dat entit, pokud se změní požadavky nebo když používáte CQRS a potřebujete přizpůsobit model čtení nebo zobrazení, která data zpřístupňují.

• Používáte CQRS a konečná konzistence je přijatelná, když se aktualizuje model čtení, nebo když entita a dosazování dat z proudu událostí vedou k přijatelnému snížení výkonu.

Tento vzor nemusí být vhodný v těchto případech:

• Systémy mají jednoduché operace CRUD, které nevyžadují schopnost auditu, záznam ani historické obnovení stavu. Provozní režie úložiště událostí není odůvodněná, pokud jediným požadavkem jsou čtení a zápisy v aktuálním stavu.

• Prototypy, minimální realizovatelné produkty (MVP) nebo systémy mají krátkou očekávanou životnost. Počáteční investice do návrhu událostí, strategie vývoje schématu a projektování infrastruktury zřídka přináší návratnost v těchto scénářích.

• Systémy vyžadují konzistenci a aktualizace dat v reálném čase. Konečná konzistence mezi úložištěm událostí a projekcemi je nedílnou součástí modelu Event Sourcing.

• Domény, ve kterých jsou data většinou statická nebo slouží jako reference, například vyhledávací tabulky nebo katalogy. Tento typ dat se mění zřídka a nemá užitek z historie změn.

• Týmy nemají zkušenosti s architekturami řízenými událostmi. Event Sourcing mění způsob testování, ladění a provozu systému. Přijetí bez základních znalostí zvyšuje riziko antipatternů, které jsou nákladné na obrácení.

Návod

Event Sourcing nemusí být pro celý systém rozhodnutím úplně nebo nic. Použijte ji selektivně na části systému, které má největší výhody, jako je například registr plateb nebo kanál zpracování objednávek. Tradiční CRUD používejte pro části, pokud složitost není odůvodněná, jako je správa profilů uživatelů nebo konfigurace aplikace.

Návrh úloh

Vyhodnoťte, jak použít model Event Sourcing v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Tento model může usnadnit obnovení stavu, pokud potřebujete obnovit úložiště stavu, protože zaznamenáváte historii změn v složitých obchodních procesech. - Dělení dat - RE:09 Zotavení po havárii
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Tento model, obvykle v kombinaci s CQRS, vhodným návrhem domény a strategickým snímkováním, může zlepšit výkon při zátěži díky atomickým operacím pouze pro přidávání a vyhnutí se zamykání databáze během zápisu a čtení. - PE:08 Výkon dat

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Příklad

Systém řízení konferencí musí sledovat počet dokončených rezervací pro konferenci. Sledováním tohoto čísla může zkontrolovat dostupná místa, když se potenciální účastník pokusí provést rezervaci. Systém může uložit celkový počet rezervací pro konferenci alespoň dvěma způsoby:

• Systém může ukládat informace o celkovém počtu rezervací jako samostatnou entitu v databázi, která obsahuje informace o rezervacích. Když účastníci dělají nebo ruší rezervace, systém toto číslo zvýší nebo sníží. Tento přístup je teoreticky jednoduchý, ale může způsobit problémy se škálovatelností, pokud se velký počet účastníků pokusí rezervovat místa během krátkého časového období. Například k tomuto nárůstu obvykle dochází v posledním dni před uzavřením období rezervace.

• Systém může ukládat informace o rezervacích a zrušeních jako události uchovávané v obchodě událostí. Vypočítá počet dostupných sedadel opětovným přehráním těchto událostí. Tento přístup může být škálovatelný kvůli neměnnosti událostí. Systém potřebuje jen číst data z úložiště událostí nebo přidávat data do úložiště událostí. Nikdy neupravuje informace o událostech o rezervacích a zrušeních.

Následující diagram znázorňuje, jak můžete použít model Event Sourcing k implementaci subsystému rezervace míst v systému pro správu konferencí.

V horní části diagramu představuje pole prezentační vrstvu. Šipka označená zapisuje body z prezentační vrstvy do pole, které obsahuje obslužné rutiny příkazů a obchodní objekty. Šipka označená jako získání událostí dostupnosti sedadel směřuje z té krabice do úložiště událostí. Šipka označená jako místo je rezervováno (počet míst) ukazuje od okna obsluhovatelů příkazů na okno označené frontou nebo tématem. Šipka ukazuje z fronty (queue) nebo okna tématu na obslužnou rutinu události. Další šipka ukazuje z obslužné rutiny události do úložiště událostí.

Stáhněte si soubor aplikace Visio s touto architekturou.

Workflow

Následující pracovní postup odpovídá předchozímu diagramu:

1. Uživatelské rozhraní vydá příkaz k rezervaci sedadel pro dva účastníky. Příkaz zpracovává samostatná obsluha příkazu. Obslužná rutina příkazu je část logiky, která je oddělená od uživatelského rozhraní a zodpovídá za zpracování požadavků odeslaných jako příkazy.

2. Systém vytvoří entitu, která obsahuje informace o všech rezervacích konference tím, že přehraje události popisující rezervace a zrušení. Tato entita se nazývá SeatAvailabilitya je obsažena v doménovém modelu, který zveřejňuje metody pro dotazování a úpravu dat v entitě.

   Návod

   Zvažte optimalizace, jako jsou snímky, abyste nemuseli přehrávat úplný seznam událostí, abyste získali aktuální stav entity. Snímky také udržují kopii entity v mezipaměti.

3. Obslužná rutina příkazu vyvolá metodu, kterou doménový model zpřístupňuje k vytvoření rezervací.

4. Entita SeatAvailability vyvolá událost, která obsahuje počet rezervovaných míst. Při příštím použití událostí použije všechny rezervace k výpočtu počtu zbývajících míst.

5. Systém připojí novou událost k seznamu událostí v úložišti událostí.

Pokud uživatel zruší sedadlo, systém se řídí podobným procesem, ale obslužná rutina příkazu vydá příkaz, který vygeneruje událost zrušení sedadla a připojí ho k úložišti událostí.

Systém může poskytnout kompletní historii nebo záznam auditu rezervací a zrušení konference pomocí obchodu událostí. Události v úložišti událostí představují přesný záznam. Entity nemusíte uchovávat žádným jiným způsobem, protože systém dokáže události snadno přehrát a obnovit stav k určitému bodu v čase.

Další krok

• Model CQRS: Úložiště zápisu, které poskytuje trvalý zdroj informací pro implementaci CQRS, je obvykle založeno na implementaci modelu Event Sourcing. Model odděluje operace, které čtou data v aplikaci, od operací, které aktualizují data pomocí samostatných rozhraní.

Komunitní zdroje

• Neshoda objektově-relační impedance

• Event Sourcing, od Martina Fowlera: Původní popis schématu z roku 2005, který vytvořil základní slovník.

• CQRS Documents (PDF) – Greg Young: Konečný zdroj o event sourcingu a CQRS od praktikujícího, který formalizoval oba tyto vzory.

Související prostředky

Při implementaci tohoto modelu můžou být relevantní také následující vzory a pokyny:

• Model materializovaného zobrazení: Úložiště dat, které používáte v systému event sourcing, se obvykle nehodí k efektivnímu dotazování. Místo toho je běžným přístupem generovat předem vyplněná zobrazení dat v pravidelných intervalech nebo při změně dat.

• Model kompenzační transakce: Systém neaktualizuje existující data v úložišti event sourcing. Místo toho přidá nové položky, které změní stav entit na nové hodnoty. K obrácení změny se používají kompenzační položky, protože předchozí změnu nelze vrátit zpět. Článek s modelem kompenzační transakce popisuje, jak vrátit zpět práci, kterou předchozí operace provedla.

• Analýza domény pro mikroslužby: V systémech, které používají návrh řízený doménou (DDD), je entita, která vlastní eventstream, obvykle agregovanou hranici konzistence, která přijímá příkazy, vynucuje obchodní pravidla a generuje události.