Rules engine vs. domain logic - JavaZone 2009

Anders Sveen

Bent Are Melsom

10.09.2009

Rules engines vs. domain logic- et balansert syn på en hårfin balansegang

Together. Free your energies 2Rules engines vs. domain logic© Copyright Capgemini 2009 All Rights Reserved

Bent Are MelsomSjefskonsulent, leder Java avdeling i [email protected]

Anders SveenSjefskonsulent, teknologileder for Java i [email protected]

Takk for at du hører på oss i dag


Agenda

Hva er en regelmotor, og hva skal/skal du ikke bruke den til

Hva lover en regelmotor deg?

Litt om RETE – basisen i en regelmotor

Hva må du vurdere før du tar i bruk en regelmotor

Erfaringer og alternativer

Spørsmål?

Oppsummering


Hva er en regelmotor?

Avansert software for å hjelpe med forretningslogikk som har sin rot i store komplekse datasett.

• Slags data mining som skjer i bakgrunnen her

• Muligheten til å la forretningsfolket kode

To typer regelmotorer – ofte i samme pakke• Inference – Håndterer slags if-then logikk

Oftest brukt i applikasjoner, og veldig ofte stateless.

• Event-condition – Detekterer events og gjør noe basert på disse

Mange leverandører, både open source og lukket.• Jrules ,Drools, InRule, Blaze Advisor etc.

Bruksområder: Beregninger, beslutninger, varsling, tilgangskontroll, data mining


Hva er en regelmotor?

Regel DSL• ”Naturlig” språk

• Tabeller

• Deklarativt

RETE algoritmen• Håndterer regelsett med effekter på tvers av regler

Omkringliggene verktøy• Skrive regler

• Debug

• Repository


Regelevaluering og RETE

1. Hvis ekstern catering er booket, avbestill kjøkkenet

2. Hvis Storsalen er booket, innkall ekstra hjelp

3. Hvis Storsalen er booket, øk prisen med 10%

4. Hvis antall påmeldte er over 100, book ekstern catering

5. Hvis antall ledige plasser igjen er under 50, øk prisen med 15%

6. Hvis maks plasser for arrangement er over 100, book Storsalen

Re

ge

l 1

Re

ge

l 2

Re

ge

l 3

Re

ge

l 4

Re

ge

l 5

Re

ge

l 6


Hva ”lover” en regelmotor?

Regler kan endres mens systemet kjører

Regler kan endres uten at utviklere må blandes inn

Regler er i naturlig språk og derfor bedre dokumentert

Synlighet i beslutninger

Raskere utvikling


Regelmotor vs ”røkla”

Separation of concerns

Enklere kommunikasjon

Automatisert test

Rik domenemodell

Felles begrepsapparat

JUnit + Fitnesse + Maven


Trenger du en regelmotor?

Når du snubler i if-setninger – skriving av dette er ren pain• Sørg for at du objektorienterer før du vurderer en regelmotor

• Hvilke deler av domenet passer i en regelmotor. Kan innføre en regelmotor etter hvert som du ser at du trenger det.

Hyppige forandringer i forretningslogikken?• som ikke krever endring i informasjonsgrunnlaget?

Skal du hurtig skalere antall utviklere?• Regelmotor kan gi deg strukturen du trenger.

Må du gjenskape en komplisert beslutning tilbake i tid?

Trenger du versjonering av regler?

Gjør en PoC med både regelmotor og et godt designet domene.


Hva må du tenke på når du innfører en regelmotor?

Ytelse• Hvor fort må det gå? Hva tar tid? Motoren eller innhenting av informasjon?

Implementasjonsytelse• Hvor fort og enkelt kan man implementere reglene?

• Mange regelmotorer har gode ”WYSIWYG” editorer som funker for forretningsfolkene. Disse funker godt på mindre regelsett, men sliter ofte på store.

Tjenestemoduler• Skille ut bygging av input/output fra regelmotor

• Massering av resultatet fra regelmotoren?

• Felles eller separat domenemodell?

Feilhåndtering?

• Hvordan få til funksjonelle feil ut av regelmotoren?

Er den så “blackbox” som du tror?


Konsekvenser i prosjekt Du får ofte flere grupperinger, og dermed større roundtrip i utvikling

Kompleksitet i utviklingsmiljøet, flere produkter å installere, tyngre kjøremiljø

Testing – flere steder med automagisk testing. • Flere rammeverk – trenger du nok ett rammeverk

Blackbox vs. whitebox for deg som javautvikler• kompetanse i prosjekt

Re

ge

lgru

pp

en

ko

de

r

Du

so

m u

tvik

ler

Tes

t

De

plo

y

Tiden går jo lengre roundtrip du har


Erfaringer

Regelmotor letter kommunikasjonen• Trenger uansett et felles begrepsett

Automatisk testing hindrer feil ved endringer• Gjelder uansett teknologivalg

Det er teknologene som ender opp med å skrive reglene• Til syvende og sist sitter utvikleren med jobben

Feil er vanskelig å finne ut av• Ref. blackbox


Erfaringer forts.

Verktøyene er ofte ikke gode utviklingsverktøy (IDE)

• Mangler ofte auto-complete osv.

Pek og klikk er ikke så lurt som det høres ut som

Ikke kompatibelt med vanlig kildekodekontroll• Hva skjer dersom repo ryker?

Å fjerne regler fra koden gjør koden mindre forståelig• Du kan fort ende opp med en anemisk domenemodell

Avhengig av konsulenter fra leverandør• Hvem ender opp med å ha kontroll på reglene?


Alternativet?

Objektorientering

Med god objektorientering og Domain Driven Design kommer du langt Enkelt for utvikler å forholde seg til Trenger god og tett kommunikasjon mellom utvikling og forretning. Det trenger du

vel uansett?

Domain specific languages

Språk spesielt laget for spesielle problemer og domener Ide adoptert fra “special purpose languages” – ikke nytt med andre ord.

Oppslagstabeller

Enkel tabell (ofte in memory) hvor du slår opp et sett med verdier og får ut en

handling som retur.


Spørsmål?


Oppsummering

Trenger du RETE?

Dersom du har meget komplekse datasett Sammenhenger på tvers av meget komplekse datasett Kan utfallet av en regel påvirke beslutningsgrunnlaget for en annen regel?

Hvordan håndterer du kompetanse rundt en regelmotor?

Få på plass et felles begrepssett mellom forretning og utvikling Regelmotor tar bort noe kompleksitet, men innfører og mye

Vurder etterhvert

Bruk objektorientering så langt det går – I mange tilfeller trenger du ingen

regelmotor


Takk for oss!

[email protected]@capgemini.com

Documents

Rules engine vs. domain logic - JavaZone 2009