Morn!

morn

Mornings!

Mornmorn!

Er det noen som har erfaring med å bruke en "rules engine" som f.eks. https://github.com/cerner/clara-rules eller https://github.com/oakes/odoyle-rules for å gi forretningsfolk muligheten til å definere forretningslogikk (og kanskje presentasjonslogikk) selv eller gjøre det enklere/raskere for utviklere å gjøre det? :thinking_face: Vi har noen mikrotjenester og mikrofrontends hvor forretningen stadig ber om endringer i "enkel logikk" for å speile endringer i markedet, nye produkttyper og forretningsmodeller, leverandøravtaler, etc. Der kunne det kanskje kunne vært aktuelt å bruke noe slikt.

Jeg har som regel vært litt skeptisk til sånne greier. De er bygget for å håndtere vilkårlig vanskelige regelstrukturer, det er min erfaring at reglene som regel er ganske enkle. Og hvis de ikke er det, så burde de vært det. Det som derimot kan være gunstig er å late som om du har en regel motor og skrive reglene dine på en slik måte at de er enkle å endre på. I sin ekleste form er jo en regelmotor bare en reduce over en liste med regler der du returnerer reduced hvis en regel feiler.

Ja, hvis man er litt banal, kan man vel si at forretnings- og presentasjonslogikk er selve kjernen til en app. Hvis man tar det ut av appen, så står man vel "bare" igjen med user/session management, dataflyt, state management og evt. persistering av data in en database.

Datadrevne løsninger er lettvekts regelmotor som du kan lage selv og lett endre på

Jeg føyer til "mikrofrontender" på lista over ting jeg rynker litt på nesa av 😅

Det forstår jeg etter å ha sett din siste presentasjon! Hehe.

Vi er så og si all-in på det motsatte av det du foreslår der 😂 Med masse frittstående frontend "komponenter" som kombineres i større "sider." Så vi har ikke det pene top-down treet som du viste frem, men den andre modellen hvor det er litt uforutsigbart når ulike komponenter oppdaterer seg, etc.

Hver sin smak!

Microfrontender dytter Conway rett i fleisen på brukeren. I stedet for å ha ett team som har som ansvar å gi brukeren en enhetlig brukeropplevelse så sier man bare fuck it, og lar brukeren forholde seg direkte til intern organisering. Hvis enhver kunde av produktet treffer på mange team i sin reise stiller jeg meg kritisk til at det er en god løsning.

Det er sikkert mulig å få til noe bra med det, men jeg vil påstå at det er på "hard mode".

Helt enig med @slipset her. Igjen er data tingen. 😊 Hvis du bygger reglene som data, så kan disse komme fra "hvor som helst" - inkludert databasen, om man skulle ønske det. Anbefaler forøvrig å bruke mye lister i regler. Altså, at man ikke har et config-map med kun skalarer for en regel, men at en regel støtter seg på en liste som kan legges til og fjernes fra. Eksempelvis kan første elementer i lista som "slår til" vinne - eller hvert element i lista kan bidra med et tall.

Interessant! Jeg opplever også at microservices + microfrontends har ganske høy kompleksitet og mye overhead. Det er lagt opp til å gjøre utviklingen av individuelle deler løst koblet og mer autonomt, og slik at ulike deler kan deployes separat, etc. Men kostnaden er antagelig høyere enn verdien. En kunne sannsynligvis oppnådd enklere løsninger og mindre overhead ved å gå for monorepo, trunk-based development, og andre komplementerende metoder. Og deployment modellen kan sikkert løses på en annen måte også.

FC/IS blir vel også ganske “regelmotor-nært”. Ref Magnar sin analogi om at FC/IS er som en president som bestemmer hva som skal gjøres (FC), og en executive branch som gjør det (IS)

Som jeg hintet til, men kanskje ikke sa rett ut. Forretningsfolk elsker å finne på sinnsykt kompliserte regler, typ hvis du handler viss oss tre tirsdager på rad i mai, så får du 3.5 bonuspoeng gitt at fornavnet ditt begynner på P. Dessverre elsker vi utviklere å abstrahere over slike ting og lage generiske rammeverk for å støtte opp under slik idioti. Det vi burde gjøre er simpelthen å si «Nei!». Lag bra produkter til en grei pris og plutselig så forsvinner behovet for en regelmotor.

Det er ekstremt mange slike regler i retail generelt. Et hypotetisk men realistisk eksempel: "Hovedprodukter fra leverandør A kan kun presenteres sammen med kompatible tilbehør fra samme leverandør, eller leverandør E men kun utvalgte produktgrupper i kampanjeperiode D, og kun hvis tre av leverandør A sine egne tilbehør presenteres først med mindre disse ikke er på fjernlager Y for øyeblikket eller vi har fått en bekreftet innkommende dato innenfor én uke, eller på lager i en butikk mindre enn 10 km unna kundes postnummer […]" Som @slipset sier: Forretningsfolk elsker å lage regler sammen med leverandører, og ofte er de kontraktsfestet i tillegg før vi har de tekniske mekanismene for å kunne implementere dem.