Plus “policy” – del 1

(English edition)

Jeg har efterhånden nævnt Plus kontoer på vores eksperimentielle site www.miljoparkering.se nogle gange, men det har altid været i forbindelse med andre emner her på eventdriven.dk.

Når jeg er i dialog med forretningsansvarlige og andre arkitekter, og beskriver den Plus policy vi bruger www.miljoparkering.se, samt hvor relativt let det var at indføre den på sitet, får jeg typisk meget positiv feeback. Noget af det kan muligvis stamme fra min entisuasme når jeg fortæller, da det er et ret godt eksempel på hvordan man kan bruge NServiceBus-sagaer i modelleringen og programmeringen af en sådan forretningsregel. :-)

Så jeg tænkte det måske var en god idé at beskrive den her, så jeg kan dele entusiasmen og viden med flere:

Miljöparkering Plus giver brugeren adgang til flere features. En bruger opnår Plus når de opretter deres konto (30 dages teaser), og derefter ved enten at invitere nye brugere eller betale via SMS. Plus er forretningsmæssigt og tidsmæssigt defineret på denne måde:

Plus saga

Miljöparkering Plus saga

  1. En værdi gemmes via domænemodellen om at brugeren har Plus og et event udsendes (CustomerSetPreferredEvent).
    Plus tildeles brugeren (typisk 30 dage), og processen startes.
  2. 3 dage før afslutningsdatoen udsendes en advarsel via mail og SMS om at Plus snart udløber og at brugeren bør overveje en forlængelse.
  3. 1 dag før afslutningsdatoen udsendes endnu en advarsel, denne gang kun via mail.
  4. Plus udløber, brugeren sættes til ikke-plus.

Hvis brugeren vælger at forlænge Plus, lægges blot yderligere 30 dage til den eksisterende Plus proces.

Da denne proces følger døgnene, vil det være naturligt at henfalde til udvikling af et eller flere batchjobs, som så vil checke om nogle af de omtalte datoer er overskredne. Men hvad så med forlængelse? Ja, ok, måske ikke voldsomt svært, vi flytter bare slutdatoen og kan beregne advarselsdatoerne igen. Men hvad så når et batchjob ikke kan gennemføres pga. tekniske problemer, især hvis ingen opdager det og det derfor står stille i dagevis? Ah, så tilføjer vi da bare nogle kontrolværdier (i vores domænemodel, ikke?), så hvis datoerne overskride og vi ikke har sendt påmindelser, kan vi reagere. Men hvis dette ikke implementeres korrekt, vil udfaldet potentielt blive, at nogen brugere slet ikke vil være Plus for altid?

Ok ok, måske er disse problemer lidt kunstige, men de fleste af os ved også, at hvis vi skal håndtere ovenstående udfordringer via batchjobs, så skal der “hackes” en del og arbejdes ekstra på at sikre, at der ikke er nogle huller i løsningen.

Med NServiceBus er det lidt anderledes. Vi skaber ved CustomerSetPreferredEvent en ny instans af en saga kaldet PreferredCustomerSaga:

Bemærk, at sagaen er lavet således, at den kan acceptere flere events af typen CustomerSetPreferredEvent (hvilket er en forlængelse). Det er ikke muligt at annullere timeouts, derfor opretter vi dem med et “group id”, som er nyt for hver modtaget CustomerSetPreferredEvent. Dvs. hvis id’et er X og et nyt CustomerSetPreferredEvent kommer ind, sætter vi id’et til Y, gemmer det i saga data og med de nye timeouts. Når et timeout kommer tilbage, sammenligner vi med gældende id i saga data, og timeouten håndteres herefter eller smides væk. Bemærk her, at sagaen ikke udfører noget selv, men selv publicerer events, som håndteres et andet sted i samme service / bounded context. Det er også årsagen til, at man i nogen grad kan tillade sig at være lidt afslappet med konstanter mv., da disse ikke bleeder ud i andre services (vi eksperimenterer med type properties og / eller specifikke event typer).

Det gode ved brug af NSerivceBus er ydermere, at hvis serveren er nede eller vores NServiceBus worker på anden måde er forhindret i at udføre sit arbejde, så vil den samle op hvor den slap, da timeouts er durable.

Dette eksempel er ret ligetil. I en kommende blogpost beskriver jeg hvordan vi har brugt en saga mere til Plus – DET bliver interessant! :)

Christer Ø. on twitterChrister Ø. on linkedin
Christer Ø.
Software Development Consultant stratal ApS
Christer Østergaard er freelance forretningsanalytiker og softwarearkitekt med mere end 16 års erfaring. Har arbejdet med STAR (tidl. Arbejdsmarkedsstyrelsen), DSB, Kommunernes Landsforening, Digitaliseringsstyrelsen, Egmont, Banedanmark, Elsparefonden, Armada Shipping, Unik HR, Fødevareministeriet og Ministeriet for Flygtninge, Indvandrere og Integration, Knowledge Cube, mikz.com, Ankestyrelsen m.fl. Dertil et par Open Source projekter. Lige nu læser Christer Data and Reality. Christer er klar til at sikre leverance af nye softwareprodukter fra 1. Januar 2016.