Jobb backend rendszerek építése: Miért számít az event sourcing és a domain model?

Ha szoftverarchitektúra körül forogsz, biztos találkoztál már az event sourcinggel, a domain-driven designnal és a CQRS-sel. Ezeket mantraként emlegetik. Hangzanak okosan. Nehezeknek tűnnek. Pedig a legtöbb fejlesztő kerüli őket, vagy túlbonyolítja a dolgot.

A valóság? Ezek a minták valódi problémákat oldanak meg. Ma már sokkal közelebb kerültek hozzánk.

Milyen gondot orvosolnak?

Nézzük visszafelé. A hagyományos appokban az adatbázis a király. Felmented egy user objektumot, módosítod, újra mentesz. Egyszerű.

De mi van, ha tudni kell, mi változott, mikor és miért? Vagy vissza kell játszani a rendszert egy hibakereséshez? Esetleg összetett üzleti logikád van, ahol az állapot nem sima pillanatfelvétel, hanem sok döntés eredménye?

Itt jön az event sourcing. Nem az aktuális állapotot tárolod, hanem az eseményeket, amik ahhoz vezettek. Minden üzleti lépés – fizetés feldolgozva, rendelés létrehozva, készlet frissítve – változtathatatlan rekord lesz. Az állapot? Az csak egy olvasási modell, amit az események lejátszásából építesz fel.

Ha ezt összekötöd domain-driven designnal, ami az üzleti fogalmak köré modellezi a kódot, akkor olyan rendszert kapsz, ami:

• Automatikusan auditálható – minden változás nyomon követhető
• Könnyen debuggolható – bármikor visszajátszható
• Skálázható – különítheted az írásokat az olvasásoktól
• Üzletközeli – a kód követi a valós logikát

A gondolkodásmód a kulcs

Itt akad el a legtöbb projekt. Az event sourcing és DDD másképp gondolkodást kér a domainről. Aggregátumokat kell azonosítani (kapcsolódó objektumcsoportok), parancsokat definiálni (ami változást okoz) és eseményeket modellezni (ami tényleg megtörtént).

Ha elrontod, bonyolult, érthetetlen rendszer lesz. Ha jól csinálod, a architektúra önmagát dokumentálja.

A baj? Nincs struktúrált módja a modellek rögzítésének. Felrajzolod táblára, vagy a fejedben tartod. Ez gondot okoz:

• Új csapattagok bevezetésekor
• Üzleti oldalú megbeszéléseken
• Eszközök fejlesztésekor, amik értik a domaint
• AI használatakor modellek elemzésére

ESDM: Nyelv az architektúrádhoz

Itt lép be az ESDM (Event-Sourced Domain Modeling). YAML-alapú nyelv, ami kifejezetten event-sourcing rendszerek elemeit fogja meg:

• Aggregates – fő üzleti egységek
• Events – mi történt
• Commands – mi indította el
• Read Models – hogyan kérdezed le
• Process Managers – többlépéses folyamatok irányítása
• Context Mappings – domainek közti kommunikáció

Miért YAML? Olvasható embernek, de elég struktúrált eszközöknek. Főleg, hogy LLM-ek közvetlenül értik és írják.

Az AI segít

Modern csapatokban izgalmas ez. Ha AI-t használsz kódgenerálásra, miért ne domain modellekre is?

Add meg a meglévő kódot egy LLM-nek, és kihúz belőle egy event-sourcing modellt. Nullaról indulsz? Segít vázlatot rajzolni. A YAML doksi és truth source egyben.

Nem helyettesíti a szakértelmet – valaki ellenőrizze, hogy üzletileg stimmel. De felpörgeti a "így működik az üzlet" és "így épüljön a rendszer" közti ugrást.

Útburkolat a te szintedre

Nem minden csapat ugyanott tart:

Első alkalom? Alapokból indulj, példákon keresztül. Útmutatók visznek az "mi az aggregate?"-től a első modelledig.

Már event-sourcingozol? Dokumentáld. Formális modell segít onboardingben, eszközökben, döntésekben.

Eszközt építesz domainekhez? A séma a szerződésed. Validátorok, generátorok, IDE-k mind erre épülnek.

AI-ra támaszkodsz? Az ESDM struktúrája miatt az LLM-ek értelmesen dolgoznak vele, nem csak kamu kódot köpnek.

Nagyobb kép

Event sourcing és DDD nem csodaszer. Hozzáadnak komplexitást. De oda, ahová érdemes: auditálhatóság, skálázhatóság, domain tisztaság.

A változás a toolingban van. Ha standard formátumban rögzíted a modellt, validálod, kódot generálsz belőle, az adoptáció könnyebb.

AI-val még gyorsabb: "modellezzünk domaint" helyett "itt az ESDM fájl, ami mindent leír".

Mit jelent ez neked?

Ha olyan rendszert építesz, ami:

• Hosszútávon karbantartható
• Auditálható, megfelelőséges
• Növekvő logikával skálázható
• Új fejlesztőknek érthető

Akkor a domain modeling nem korai optimalizálás. Alap.

Kezdd kicsiben. Egy bounded context. Lásd, mennyire tisztább lesz a fejed. Iterálj. Használj AI-t vázlatra. A struktúra számít.

A jövőbeli éned (és csapatod) hálás lesz egyértelmű nyilvántartásért: nem csak mit csinál a rendszer, hanem miért.