Obsah
- Proč mi tento způsob uvažování připadá blízký
- Co si systém vlastně pamatuje?
- Nemusím dnes znát všechny zítřejší otázky
- Když je chyba v pohledu, ne v historii
- Události potřebují souvislosti
- Paměť má svou cenu
- Co z toho vzniká v aplikaci
- Proč se k tomu vracím právě dnes
- Kde pro mě přirovnání končí
- Od porozumění ke zvnitřnění
- Zdroje a podklady k dalšímu studiu
Proč mi tento způsob uvažování připadá blízký
Když se snažím pochopit člověka, firmu nebo problém, samotný současný stav mi většinou nestačí. Potřebuji vědět, co se stalo předtím. Jaká rozhodnutí padla, co na co navazovalo a jak jsme se dostali do bodu, ve kterém jsme dnes.
Takhle se na věci dívám dlouhodobě.
Při studiu a používání Event Sourcingu jsem si postupně uvědomil, že právě proto je mi tenhle přístup blízký. Zachovává události, ze kterých stav vznikl, a umožňuje ho z nich znovu sestavit. [2]
Připomíná mi to způsob, jakým si z vlastní zkušenosti skládám obraz světa.
Neberu to jako vysvětlení fungování mozku. Je to pro mě užitečná paralela — a zajímavá je i v místech, kde přestává platit.
Co si systém vlastně pamatuje?
Představme si obyčejnou objednávku.
Dnes vidíme, že je zaplacená, odeslaná a má určitou doručovací adresu. Pro vyřízení běžného dotazu to může stačit.
Jenže za tímto stavem může být například taková historie:
Objednávka byla vytvořena s adresou A.
Doručovací adresa byla změněna na B.
Platba byla přijata.
Objednávka byla odeslána na adresu B.
Každý záznam nese údaje potřebné k popisu změny. V Event Sourcingu není tato historie pouze doplňkem k aktuálnímu řádku v databázi. Pro danou část systému je základem, ze kterého stav obnovujeme. [3]
Když se teď zákazník zeptá, proč zásilka odešla jinam než obvykle, mám se k čemu vrátit.
Podobně si sám vysvětluji situace kolem sebe. Nezajímá mě pouze výsledek. Potřebuji rozumět cestě.
Jenže ani tady nesmím zaměnit záznam za celou skutečnost. Změna doručovací adresy neznamená, že se zákazník přestěhoval. Třeba jen objednává dárek.
Event store není kopie reality. Je to paměť systému o těch událostech, které jsme se rozhodli považovat za důležité.
V tom vidím paralelu s pozorností. Něčeho si všimnu, něčemu přisoudím význam a něco nezachytím vůbec.
U systému o tomto výběru rozhodujeme návrhem událostí. Doménová událost má zachytit významný děj v dané doméně, ne nutně nejmenší technický pohyb. [4] Samotný záznam kliknutí nebo stisků kláves ještě neznamená, že podle těchto záznamů rekonstruuji stav aplikace — a tedy ani to, že používám Event Sourcing. [2]
Pro pochopení ovládání formuláře může být taková telemetrie užitečná. Pro rekonstrukci objednávky mě ale zajímá především to, jaká změna byla skutečně přijata. Tyto dvě paměti mohou existovat vedle sebe. Nemusí být jednou a tou samou věcí.
Nemusím dnes znát všechny zítřejší otázky
Na Event Sourcingu mě přitahuje možnost oddělit zaznamenaná fakta od konkrétního pohledu na ně. Nad uchovanými událostmi lze vytvářet různé modely pro čtení podle toho, co potřebujeme zjistit. [5]
U naší objednávky mě dnes zajímá aktuální stav. Později se můžu ptát, jak dlouho uplynulo mezi přijetím platby a odesláním. Nebo kolikrát zákazníci změnili adresu před expedicí.
Pokud jsem potřebné události a jejich údaje zachoval, nemusím začít historii sbírat až ve chvíli, kdy mě otázka napadne.
Právě tady vidím velkou hodnotu pro business aplikace.
Požadovat na začátku projektu úplný seznam budoucích reportů mi připadá jako snaha uzavřít přemýšlení dřív, než máme nad čím přemýšlet. Pro mě je přirozenější ukázat první pohled a nechat nad ním vzniknout další otázku.
„A jak to vypadá u objednávek, kde se měnila adresa?“
Taková otázka není selhání původního zadání. Je to pokračování hledání.
Nemusím dnes rozhodnout, jaké všechny pohledy budu potřebovat. Musím ale rozhodnout, jaké skutečnosti chci zachovat.
Tahle hranice je důležitá. Když jsem nezaznamenal otevření formuláře, z historie dokončených objednávek nezjistím, kolik lidí ho opustilo. Nový pohled nevytvoří informaci, kterou nemám.
Odkládám tedy rozhodnutí o interpretaci, ne odpovědnost za návrh dat.
Když je chyba v pohledu, ne v historii
Další věc, která mě fascinuje, je možnost vrátit se k podkladům.
Představme si, že report chybně počítá dobu vyřízení objednávky od jejího vytvoření, přestože ji má počítat od přijetí platby. Události jsou správné. Chyba je ve způsobu, jakým z nich vznikl výsledek.
Opravím výpočet a projekci sestavím znovu. Nemusím odhadovat minulost z hodnoty, kterou kdysi vytvořil chybný algoritmus. Zachovaná historie umožňuje přepočet. [3]
Připomíná mi to okamžik, kdy se na starou zkušenost podívám s novým porozuměním. Událost nemusím změnit, abych změnil svůj závěr.
U systému ale potřebuji rozlišovat dvě situace. Jiná věc je chyba ve výpočtu a jiná chybná informace v samotné historii. Jestli jsme nesprávně zaznamenali přijatou platbu, přehrání stejného záznamu problém nevyřeší. Potřebuji opravu zaznamenaných skutečností, například novou opravnou událostí. [6]
Stejně tak oprava projekce nesmí znovu strhnout peníze nebo odeslat zásilku. Rekonstrukci pohledu musím oddělit od provádění skutečných operací. [2]
A časem se může změnit i jazyk, kterým události popisujeme. Starší formáty musíme dál umět přečíst — pomocí verzování nebo převodu při načítání, aniž bychom pokaždé přepisovali uloženou historii. [7]
Pro mě je podstatné rozlišit: opravu chyby, nový analytický pohled a změnu obchodních pravidel. Přepočítat minulost dnešní logikou není vždy správná odpověď. [2]
Události potřebují souvislosti
Když se snažím pochopit situaci, nestačí mi vědět, že se něco stalo před něčím jiným. Zajímá mě také, jestli spolu ty věci souvisely.
V systému nám k tomu pomáhají identifikátory návaznosti. Correlation ID propojuje zprávy jednoho procesu, causation ID ukazuje na bezprostřední zprávu, která vyvolala vznik té následující. Pomáhají rekonstruovat řetězec zpracování, nikoli automaticky odhalit všechny skutečné motivy zákazníka. [8]
Ani čas není jediná hodnota. Platba může proběhnout dopoledne, ale objednávkový systém se o ní dozví až odpoledne. Otázka „kdy se to stalo?“ je jiná než „od kdy jsme o tom věděli?“. [9]
Tohle mi připomíná situace, kdy nová informace zpětně změní moje chápání dřívějšího rozhodnutí.
V distribuovaném systému navíc nemůžu bez dalšího předpokládat jedno společné pořadí všech událostí. Musím určit, kde na pořadí záleží a jak ho zajistím. Při asynchronním zpracování mohou jednotlivé pohledy také dočasně zaostávat — to je součást toho, čemu říkáme eventual consistency. [10]
Ve firmě si to představuji jednoduše: jeden člověk už ví, že se něco změnilo, druhý ještě pracuje s původní informací. V aplikaci ale potřebujeme takové zpoždění vědomě navrhnout a uživateli srozumitelně ukázat.
A někdy stejnou informaci dostaneme dvakrát. Tady nastupuje idempotence: opakované zpracování téže události nesmí způsobit další změnu výsledku. Dvakrát doručené oznámení o platbě neznamená dvě platby. [3]
Paměť má svou cenu
Do téhle paralely mi patří i zapomínání.
Nechci tvrdit, že člověk zapomíná jednoduše proto, aby ušetřil místo. Výzkum ale ukazuje i případy, kdy potlačení konkurenčních vzpomínek omezuje jejich vzájemné rušení při vybavování. Zapomínání tedy nemusí být pouze ztráta. [11]
Pro návrh systému si z toho beru otázku: Jakou cenu má informaci nejen uložit, ale také ji dlouhodobě udržovat použitelnou?
Nejde mi jen o kapacitu disku. Potřebuji datům rozumět, chránit je, umět je zpracovat a vědět, proč je vůbec uchovávám.
Proto pro mě Event Sourcing neznamená „sbírej všechno, jednou se to bude hodit“. Znamená vědomě rozhodnout, co si má systém pamatovat a jak dlouho. Když část historie odstraním, přijímám i omezení toho, co z ní později dokážu zjistit. Podle toho, co odstraním, můžu přijít i o možnost úplné rekonstrukce původního stavu.
Vedle ceny uchování je tu cena opakovaného vybavování.
Když se mě někdo zeptá, kde pracuji, neprocházím v hlavě celou pracovní historii. Odpovím ze svého současného obrazu.
V systému mi to připomíná snapshot: uložený stav v konkrétním bodě streamu. Při rekonstrukci načtu tento stav a doplním pouze pozdější události. Snapshot zkracuje práci, ale sám o sobě nenahrazuje historii. [12]
Zapomenout informaci a nemuset ji pokaždé znovu zpracovat jsou dvě různá rozhodnutí.
Co z toho vzniká v aplikaci
Tady se pro mě úvaha vrací k praktické architektuře.
S CQRS můžu oddělit model pro změny od modelů pro čtení. Detail objednávky, pracovní přehled skladu a manažerský report nemusí používat tutéž podobu dat. Každý pohled lze přizpůsobit jeho účelu a podle návrhu také nezávisle škálovat. Není to ovšem automatická záruka vyššího výkonu. [5]
Zajímá mě i představa jednotlivých historií, které se skládají do společného obrazu. Připomíná mi lidi s vlastní zkušeností a tým, který z jejich pohledů vytváří společné porozumění.
Technicky mohou být vhodně rozdělené proudy událostí zpracovávány paralelně. Kde ale sdílejí závislosti, zůstává potřeba koordinace. Rozdělení samo neodstraní konflikty ani úzká místa. [10]
Proto bych hranici streamu neodvozoval automaticky od uživatele. Dva lidé mohou měnit stejnou objednávku. Důležité je, jaká pravidla musí zůstat společně platná.
Historie zároveň dává podklad pro funkce, které mě na této architektuře přitahují: vysvětlení změn, návrat k předchozímu pohledu nebo řízené vracení operací. „Zpět“ ale nemusí znamenat návrat celého světa do původního stavu. U odeslané zásilky už potřebujeme navazující proces, ne vymazání minulosti. [13]
Také autosave bych na této historii mohl postavit. Pořád ale musím navrhnout, co je rozpracovaná změna, co se ukládá a jak řeším souběžné úpravy.
A podobně přistupuji k auditu. Chci dohledat, kdo změnu provedl a na co navazovala. Samostatně však musím řešit například záznam čtení citlivých dat, zamítnutých přístupů nebo bezpečnostních incidentů. Historie doménových změn není totéž co kompletní bezpečnostní audit.
Tyto možnosti pro mě nejsou funkcemi zdarma. Jsou to funkce, pro které mám společný a srozumitelný základ.
Proč se k tomu vracím právě dnes
Do mého uvažování vstupuje také AI.
Nástroje dnes dokážou pomáhat s implementačními úkoly i návrhem testů. Samotná dostupnost těchto možností ale ještě nedokazuje, o kolik zlevní konkrétní projekt.
Já v nich vidím příležitost snížit množství opakující se práce kolem projekcí, zpracování událostí a ověřování různých variant návrhu.
Neznamená to, že přestávám potřebovat rozumět architektuře. Naopak: čím snazší je něco implementovat, tím důležitější je vědět, co má vzniknout a jak poznám, že to funguje správně.
Zajímá mě tedy možnost věnovat méně práce mechanické realizaci a více porozumění doméně. Ne představa, že složitost přestala existovat.
Kde pro mě přirovnání končí
Od systému nechci, aby si chybějící minulost domýšlel. Chci, aby uměl rozlišit zaznamenanou událost, odvozený pohled a informaci, kterou nemá.
A ani bohatá historie sama o sobě neznamená porozumění. Změna adresy mi řekne, co zákazník udělal. Nemusí mi říct proč.
Přesto mě právě tahle architektura vede k otázkám, které považuji za důležité i mimo software: Co skutečně víme? Z čeho náš závěr vznikl? A dokážeme se k těm podkladům vrátit?
Na Event Sourcingu mě nejvíc přitahuje možnost nezaměnit dnešní pohled za jediný možný obraz toho, co se stalo.
Sám jsem se s touhle úvahou dostal sem. Pro další posun potřebuji zkušenost ostatních.
Kde vám paralela s lidskou pamětí pomáhá — a kde už podle vás začíná zkreslovat?
Od porozumění ke zvnitřnění
Pokud si chcete tento způsob uvažování opravdu zvnitřnit, projděte si podklady na konci článku. Ne jako seznam definic k zapamatování. Vezměte si k nim situaci, kterou znáte ze své práce, a zkuste ji nejdřív popsat událostmi místo výsledného stavu.
Co se stalo? Co si potřebujete pamatovat? Jaké různé pohledy z této historie dokážete vytvořit? A co z ní naopak nikdy nezjistíte?
Pro začátek bych sáhl po textech o Event Sourcingu od Martina Fowlera a Microsoftu. [1] [2] [3] K dalším podkladům bych se vracel podle otázek, na které narazíte — ne podle potřeby projít všechny pojmy najednou.
Rád vás touto cestou provedu — od konkrétního problému přes pochopení souvislostí až k vlastnímu návrhu a jeho ověření v praxi.
Nejde mi o to předat vám další pattern. Jde mi o to, abyste si vytvořili vlastní porozumění a dokázali rozpoznat, kdy vám tento přístup pomáhá a kdy zbytečně přidává složitost.
Chcete-li se na tuto cestu vydat společně, ozvěte se mi. Můžeme začít přímo situací, kterou právě řešíte.
Zdroje a podklady k dalšímu studiu
Číselné odkazy v textu vedou na podklady k jednotlivým tématům. Paralela mezi Event Sourcingem a lidskou pamětí je moje interpretace, nikoli závěr uvedených technických zdrojů ani tvrzení, že mozek funguje jako event store.
Zdroje ověřeny 19. září 2026. U průběžně aktualizované dokumentace jde o podobu dostupnou k tomuto datu.
[1] Betts, Dominic; Domínguez, Julián; Melnik, Grigori; Simonazzi, Fernando; Subramanian, Mani. Exploring CQRS and Event Sourcing: A journey into high scalability, availability, and maintainability with Windows Azure. Microsoft patterns & practices, 2012; předmluva Greg Young. Volně dostupná kniha (PDF a EPUB, přibližně 380 stran) na Microsoft Download Center. Popisuje cestu týmu bez předchozí zkušenosti s CQRS od návrhu přes nasazení po provoz ukázkového systému, včetně referenční části o CQRS a Event Sourcingu a případových studií z praxe. Ke stažení dostupná k 20. září 2026.
[2] Fowler, Martin. Event Sourcing. 12. prosince 2005. Základní princip, rekonstrukce stavu, přehrávání historie, změny zpracování a oddělení externích účinků při replay. Autor text označuje jako pracovní materiál.
[3] Microsoft. Event Sourcing pattern. Azure Architecture Center, Microsoft Learn. Přehled návrhu, idempotence, rekonstrukce stavu a kompromisů při použití tohoto přístupu.
[4] Fowler, Martin. Domain Event. 12. prosince 2005. Zachycení významného děje v doméně a rozdíl mezi zdrojovou informací a jejím zpracováním. Autor text označuje jako pracovní materiál.
[5] Microsoft. Command Query Responsibility Segregation (CQRS) pattern. Azure Architecture Center, Microsoft Learn. Oddělení modelů pro změny a čtení, různé projekce, nezávislé škálování a související kompromisy.
[6] Fowler, Martin. Retroactive Event. 12. prosince 2005. Opravy důsledků nesprávných nebo opožděných událostí a hranice nápravy již provedených operací. Autor text označuje jako pracovní materiál.
[7] Axoniq. Event Versioning. Axon Framework Reference, verze 5.3. Evoluce formátu událostí a převod jejich reprezentace při zpracování bez nutnosti přepisovat uložená data.
[8] Axoniq. Message Correlation. Axon Framework Reference, verze 5.3. Význam correlation ID a causation ID při dohledávání návaznosti zpráv.
[9] Fowler, Martin. Bitemporal History. 7. dubna 2021. Rozlišení času platnosti skutečnosti a času, kdy ji systém zaznamenal; práce se zpětně doplněnými informacemi.
[10] Microsoft. Event-driven architecture style. Azure Architecture Center, Microsoft Learn. Pořadí událostí, asynchronní zpracování, eventual consistency, paralelismus a potřeba koordinace.
[11] Wimber, Maria; Alink, Arjen; Charest, Ian; Kriegeskorte, Nikolaus; Anderson, Michael C. Retrieval induces adaptive forgetting of competing memories via cortical pattern suppression. Nature Neuroscience, 18, 582–589, 2015. DOI: 10.1038/nn.3973. Studie o potlačení konkurenčních vzpomínek při vybavování. Není důkazem, že lidská paměť funguje jako databáze nebo že zapomínání jednoduše šetří úložnou kapacitu. Veřejně dostupný je abstrakt; plný text může vyžadovat přístup přes instituci nebo předplatné.
[12] Axoniq. Snapshots. Axon Framework Reference, verze 5.3. Snapshot jako optimalizace rekonstrukce stavu, nikoli náhrada historie událostí.
[13] Microsoft. Compensating Transaction pattern. Azure Architecture Center, Microsoft Learn. Kompenzace provedených operací a důvody, proč „zpět“ nemusí znamenat obnovení přesného původního stavu.