Brett erbjudande och hög IT-kompetens!
Genom ett långsiktigt partnerskap kan vi sätta långsiktiga mål vilket, enligt vår erfarenhet, leder till bäst resultat.
Hur fungerar systemet egentligen? Vad händer om...? Varför är det där ändrat?
Hur fungerar det där nu igen?
Att dokumentera system är svårt, ofta är dokumentation en blandning av dokument, wikisidor, ibland i form av ”arbetskort” i Jira/Trello/liknande, och ej nedskriven kunskap. Som systemutvecklare är jag ganska van att behöva undersöka specialfall i koden när någon frågar ”hur funkar det där?” eller ”varför blir det sådär”.
Hur kan vi göra dokumentationen tydligare?
Event Modeling är ett koncept/”verktyg” – en metod för att visualisera hur ett system ska fungera och fungerar, tänk att det är som en husritning där man kan se hur huset är tänkt att se ut och fungera.
- Det är inte en produkt i sig, men det finns produkter som är specialbyggda för Event Modeling med kodgenerering.
- Det hjälper dig att dokumentera och skissa på hur systemet är tänkt att fungera innan programmering görs.
- Dokumentationen utvecklas med tiden och ger en överblick och underlag för diskussioner kring nya affärsregler och vidareutveckling.
Den största Nackdelen, liksom med all annan typ av dokumentation är att det tar tid från annat arbete, som att programmera. Men att kunna rita, diskutera, modellera och visualisera på en skrivtavla (whiteboard) innan kodande kan spara in tid i just programmeringen. Och när ritningen är där förändringar görs innan det byggs vidare eller görs ändringar kan vi snabbt ser hur systemet fungerar utan att läsa kod.
Några fördelar
- En tydligare visuell kravbild ger mindre risk för felaktiga implementationer.
- En översikt som även icke-programmerare kan förstå leder till färre frågetecken och det är lättare att sätta sig in i hur ett system fungerar, både för nya och befintliga intressenter.
- En arbetsyta/”playground” där hela systemet syns gör det enklare att laborera och skissa på nya delar av systemet. Man ser beroenden i befintliga delar och nya beroenden.
Nedan visas ett förenklat exempel över flödet i ett system där en användare kan lägga till saker i en inventering och schemalägga påminnelser för dessa. Flödet visar vad som behöver inträffa från att en användare registrerar sig till att en påminnelse skickats ut för en schemaläggning.
Event Sourcing, relaterat till Event Modeling som till stor del är sprunget ur arbete med Event Sourcing – men det är inte ett måste att använda dem tillsammans.
Varför är det där ändrat? Har vi spårbarhet på det där?
Har du ibland undrat varför något i systemet hänt, eller haft behov av någon typ av spårbarhet med t ex loggning? Önskar du ibland att det gick att se hur en process i systemet rör sig över tid eller hur en användare arbetar i ett visst flöde, som t ex i en e-handel eller ett frågeformulär?
Hur kan vi få tillgång till händelser i systemet?
Event Sourcing är ett koncept/teknik för att lagra data där varje händelse sparas och nuläget för din data bygger på historiken – vilket betyder att spårbarheten i systemet till stor del är inbyggd.
- Ett bra exempel som många kan relatera till är ett bankkonto, där nuvarande saldo är resultatet på tidigare transaktioner – summor sätts in och tas ut.
Det är alltså inte ett nytt koncept, men många applikationer byggs än idag på ”traditionellt” vis där man uppdaterar data genom att skriva över det befintliga värdet (en stor anledningen är att datalagring kostar pengar, men idag inte lika mycket som förr i tiden).
Det är inget fel i sig och för viss typ av data finns inget behov av att se historiken, men i många system är man faktiskt intresserad av historiken utifrån olika behov – ibland uppkommer behoven som möjligheter när data är tillgängligt.
Några fördelar med Event Sourcing
- ”inbyggd” loggning/spårbarhet, eftersom alla händelser sparas,
- analys av användares beteende i systemet över tid,
- för att upprätthålla standarder,
- tillmötesgå lagar och interna affärsregler.
- Ytterligare en fördel är att man i framtiden kan komma på användningsområden med befintlig data.
I bilden nedan visas ett exempel på händelser (events) tillhörande en orders beställningsflöde. Vi ser sju händelser över tid och vid vilken tidpunkt de inträffade – den här typen av data gör det möjligt att spåra och agera på händelser i systemet;
ett exempel kan vara att vi vill följa upp en skapad order som inte blivit beställd eller annullerad inom en viss tid, kanske vill vi kontakta kunden, kanske har vi reserverat produkter under en period och vill släppa reservationen, kanske vill vi stänga ordern.
För ett exempel på Event Modeling med tillhörande kod och resultat från en orderprocess se denna artikel.
learning-tutorial-event-modeling-event-sourcing-eventuous-eventstoredb-mongodb/
Artikeln är riktad till systemutvecklare men kan vara intressant att titta på även för dig som inte skriver kod.
Se även Event Modeling för en mer ingående förklaring med exempel och dess bakgrund – https://eventmodeling.org/posts/what-is-event-modeling/
För mer om Event Sourcing finns det en uppsjö av artiklar och videos ”där ute”, här är några exempel för den nyfikne.
- https://jimi.se/brick-by-brick-the-power-of-event-sourcing/ En tidigare artikel om varför jag anser att Event Sourcing passar de flesta system.
- https://zimarev.com/blog/event-sourcing/introduction/
- https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing
finns även på svenska (engelska rekommenderas då översättningar ibland blir lite svårare när tekniska termer får andra namn, men om du vill) https://docs.microsoft.com/sv-se/azure/architecture/patterns/event-sourcing