FlightSearchProducer

[pjwalstrom]

er tenkt at integrasjonene skal implementere dette interfacet, men dumt å returnere FlightSearchResponse. Burde vel heller sende en Event til en Listener om at nå er resultatet klart? Hva tror dere om det?

(har pusha FlightSearchProducer)

[audunstrand]

Hvis man skal kjøre den isApplicable greia, tror jeg kanskje det er smart med en litt mer regelmotor tilnærming. Man koder opp noen regeltemplates f.eks.
notAllowedToSell(Airline, Destination) som kan legger inn i produceren for å slippe å ha så mye duplisert kode. Hvis endringstakten er høy på slike regler kan man vurdere å bruke en database eller noe for å styre instansene. Da kan alle producere som trenger det bruke den regelen.

Egentlig et perfekt sted å prøve noe funksjonell kode, siden regler veldig fint kan utrykkes slikt

Og ja den bør jo ikke returnere en respone. Den bør produsere noe som sendes vider, også kommer svaret på en annen kø.

[pjwalstrom]

👍

• endra til å sende svaret på en kø
• regler, snakker vi drools? :-)

[audunstrand]

Synes kanskje drools er litt overkill. Tipper det er ganske raskt å lage selv.
Handler jo veldig om hvordan man forventer at endringstakten er?

Men dette minner jo veldig om sånn vi hadde det i cos messaing, og det er jo egentlig bare en enkel regelmotor. Men tenk f.eks. om man et flyselskap begynner å fly til en ny by. Om man har regler som begrenser hvem man spør basert på det, så må man deploye ny kode for å åpne for dette. Om man har regelinstanser i en databse, og dette leses opp ofte, så er man mye mer endringsdyktig.

[gtcno]

Men nå skal vi jo deploye kontinuerlig og ikke 4 ganger i året.

[audunstrand]

Selv om man har kontinuerlig deployment, så er det ikke noe grunn til å ha slike ting definert i kode. Har man det i kodeverk, vil man kunne snu seg mye raskere.

[espenkm]

For guds skyld ikke drools. Det blir bare rot.

[audunstrand]

Enig i det. Er mer det konseptet jeg tenkte på

[pjwalstrom]

tror vi lar denne oppgaven ligge til dere kommer i mars :-)