Paremmat backendit: Miksi event sourcing ja domain-mallit ovat tärkeitä

Olet varmaan kuullut puhuttavan event sourcingista, domain-driven designista ja CQRS:stä. Ne kuulostavat fiksuilta mutta vaikeilta. Monet kehittäjät välttelevät niitä tai sotkeutuvat yliyksityiskohtiin.

Todellisuudessa nämä mallit ratkaisevat oikeita ongelmia. Ja ne ovat nyt helpommin lähestyttäviä.

Mikä ongelma ratkeaa?

Perinteisessä arkkitehtuurissa tietokanta on totuuslähde. Tallennetaan käyttäjä, muokataan ja tallennetaan uudelleen. Helppoa.

Sitten tarvitset tietoa muutoksista: mitä tapahtui, milloin ja miksi. Tai haluat toistaa systeemin debugataksesi vanhan bugin. Tai domain on monimutkainen, jossa tila syntyy kymmenistä päätöksistä.

Event sourcing muuttaa pelin. Sen sijaan että tallennat tilan, tallennat tapahtumat, jotka sen aiheuttivat. Jokainen toiminto – maksu käsitelty, tila luotu, varasto päivitetty – on muuttumaton loki. Nykytila syntyy toistamalla tapahtumia.

Yhdistettynä domain-driven designiin, joka mallintaa koodin bisneksen ympärille, saat systeemejä, jotka ovat:

• Auditointivalmiita – kaikki muutokset tallessa
• Debugattavia – voit palata mihin tahansa hetkeen
• Skaalautuvia – erotat kirjoitukset ja lukemisen
• Bisnesläheisiä – koodi heijastaa logiikkaa

Ajattelun haaste

Useimmat projektit kaatuvat tähän: event sourcing vaatii uutta tapaa ajatella domainia. Tunnistat aggregaatit (liittyvät objektit), komennot (muutokset aiheuttavat toiminnot) ja eventit (mitä todella tapahtui).

Tehty väärin, systeemi on sekava. Tehty oikein, arkkitehtuuri dokumentoi itse itsensä.

Ongelma on, että malleja ei tallenneta strukturoidusti. Ne jäävät piirtoon tai päähän. Se hankaloittaa:

• Uusien tiimiläisten perehdyttävää
• Bisneskeskusteluja
• Työkalujen rakentamista
• AI:n käyttöä mallien luonnoksissa

ESDM: Kieli arkkitehtuurillesi

Tähän auttaa ESDM (Event-Sourced Domain Modeling). Se on YAML-pohjainen kieli event-sourced -systeemeille:

• Aggregates – ydintoiminnot
• Events – tapahtumat
• Commands – syyt tapahtumiin
• Read Models – kyselyrakenteet
• Process Managers – prosessien ohjaus
• Context Mappings – domainien välinen viestintä

YAML on luettava mutta työkalukelpoinen. Ja yksinkertainen tarpeeksi, että LLM-mallit ymmärtävät ja tuottavat sitä.

AI muuttaa peliä

Nykykehityksessä AI auttaa koodissa. Miksi ei domaineissa?

Syötä koodisi LLM:lle, ja se poimii event-sourced -mallin. Aloita tyhjästä? AI luonnostelee rakenteen. YAML-tiedosto on dokumentti ja työkalujen lähde.

Ei korvaa asiantuntemusta – bisnes pitää ymmärtää ja validoida. Mutta nopeuttaa siirtymää "tässä domainimme" → "tässä systeemin rakenne".

Eri tiimit, eri lähestymistavat

Event sourcing ei sovi kaikille samalla tavalla:

Aloittelija? Opi perusasiat esimerkeillä. Opit aggregaateista malliin asti.

Jo event-sourced -systeemi? Dokumentoi se. Helpottaa perehdytystä ja päätöksiä.

Rakennetaan työkaluja? ESDM on sopimus. Validointiin, koodigeneraattoreihin, IDE-plugineihin.

Käytät AI:ta? Strukturoitu formaatti tekee siitä fiksua apua, ei vaan pseudokoodia.

Kokonaiskuva

Event sourcing ja DDD eivät ole taikapulverit. Lisäävät monimutkaisuutta. Mutta oikeisiin suuntiin: auditointiin, skaalaukseen ja selkeyteen.

Työkalut muuttavat kaiken. Kun domain-malli on standardissa muodossa, validoidaan ja generoidaan koodia, käyttö helpottuu.

AI:n kanssa mallit syntyvät nopeammin. Saat ESDM-tiedoston, joka kuvaa systeemin toiminnan.

Mitä tämä tarkoittaa arkkitehtuurillesi?

Jos rakennat systeemejä, jotka ovat:

• Pitkään ylläpidettäviä
• Auditointikelpoisia
• Kasvavia bisneksen mukana
• Helppoja ymmärtää

Domain-mallinnus ei ole turhaa. Se on perusta.

Aloita pienestä. Malleja yksi bounded context. Huomaat selkeyden. Kehitä. Käytä AI:ta luonnosteluun. Rakenne ratkaisee.

Tuleva minäsi (ja tiimisi) kiittää, kun tiedossa on ei vain mitä systeemi tekee, vaan miksi.