Domain-Driven Design Europe 2023

I år var jeg tilbake på DDD Europe.  Jeg reiste ned alene, og leide sykkel som er en glimrende måte å komme seg til og fra konferanseområdet og ellers rundt i Amsterdam på.   Så et tips å ta med seg er: bruk sykkel som transportmiddel om du er i Amsterdam, alt er veldig tilrettelagt for syklister i forhold til hvordan det er hjemme.

Det ble lite alenetid, for det viste seg at det var mange kjente fra Norge på konferansen. Jeg traff på folk fra Boitano, Forse, Webstep, Computas, Scienta, Cowork, Nav, Entur og Equinor.

Noen av dem hadde jeg jobbet med tidligere for mellom 10 og 20 år siden på Telenor OMS, Nav, SPK og Valgdirektoratet.

Torsdag 8. juni.

Kl. 9.30 - Red Room

Første foredrag var "Systems thinking in large-scale modeling" av Xin Yao, en dansk konsulent med bakgrunn fra Danske bank. Hun snakket om hvorfor nye initiativ i en organisasjon ofte har god fart i starten, men dabber av etterhvert og kanskje ikke blir til noe, og brukte systemarketyper der vekst blir balansert av ressursmangel for å forklare dette. Systemtenkning har blitt et populært tema innen arkitektur og teamteori og er verdt å titte mer på.

Kl. 11.00 - Blue Room

Deretter hørte jeg "Balancing Coupling in Software Design" av Vlad Khononov. Dette var mer praktisk og tok for seg utfordringene med kobling og hvordan kobling beskrives i Structured design og Connascence. Tre parametre kan benyttes for å beskrive kobling og konsekvenser av den:

• styrke (strenght): er koblingen slik at den ligger i samme kodebase (sterk), eller er den gjennom et veldefinert API (svakere)
• endringshyppighet - hvis noe aldri endres er det ikke farlig å ha en sterk kobling mellom moduler
• avstand - en sterk kobling internt i en klasse er uproblematisk, men en sterk kobling mellom to organisasjoner kan være vanskelig å koordinere.

«Smerten» ved kobling varierer med disse tre parametrene.

Kl. 12.00 - Blue Room

I "DDD in large product portfolios" av Andreas Pinhammer var temaet systemutvikling i et tysk forsikringsselskap.  Et poeng å ta med herfra var at det er lurt å dele opp domenet i produktspesifikke og mindre produktspesifikke områder, egentlig ikke noe nytt, muligens.

Kl. 14.30 - Red Room

Etter lunsj første dag var det så «Evolution Patterns of Sociotechnical Systems» av Amal Tahri.  Her var det også fokus på systemtenkning og ulike systemarkitektyper.

Kl. 15.30 - Blue Room

Neste sesjon var mer praktisk med en kjenning fra JavaZone: «Strategic Domain-Driven Refactorings» av Henning Schwentner.  Han tok for seg hvordan man bør skrive om legacy systemer, blant annet ved å bruke «strangler» pattern og komme seg bort fra det noe leie utgangspunktet beskrevet i bildet under:

Kl. 17.00 - Red Room

Så var det duket for dagens, og kanskje konferansens høydepunkt: «Bridging the Gap: Residuality Theory and Domain-Driven Design», Cyrille Martraire og Barry O'Reilly.  Barry jobber med en doktorgrad knyttet til «residuality theory» som er en metode for å lage robuste systemer ved å utsette systemer for stress gjentatte ganger og iterativt bygge videre på de delene som ikke brøt sammen.

Han holdt en talk på DDD Europe i fjor: “An Introduction to Residuality Theory - Barry O'Reilly - DDD Europe 2022” som han også holdt på NDC og på en meetup på Rebel nylig.

Dette er spennende saker som er verdt å ta en titt på.  Det kan kreve noen repetisjoner å forstå hvordan teorien henger sammen.

Ofte er det slik at vi lager en arkitektur basert på erfaringene vi har gjort oss gjennom flere år som utviklere og arkitekter.  Vi klarer ikke alltid å si hvorfor dette er en bra arkitektur, men vi bare vet det.  Barry O’Reilly lager en måte å tallfeste hvorfor en arkitektur er bedre enn en annen, basert på en analyse av noder, koblinger og bias (føringer, struktur) i systemet.

«Post-structuralism» var et begrep som ble brukt.  Et slags paradigmeskifte etter flere tiår med strukturert design.  Men han var åpen for at ideene kan bli avfeid.

Selv tror jeg vi kommer til å høre mer fra den kanten.

Fredag 9. juni.

Fredagen tok jeg en rolig morgen og startet dagen med en workshop: «Wardley Mapping - Getting started with collaborative mapping» av Tom Asel.  Det er en metode for å få en oversikt over nåværende situasjon i en organisasjon og hva som må endres for å nå målsituasjonen.  Simon Wardley utviklet metoden for å gi bedriftene flere muligheter enn å leie inn dyre ledelseskonsulenter for å få til endringer.  Jeg havnet på gruppe med “keynote speaker” Xin Yao som er profesjonell workshop fasilitator, så det var ingen tvil om hvem som var best egnet til å ta kontroll på post-it-lappene.

Kl. 14.30 - Blue Room

Så var jeg på “Entropy in Software, DDD, and Constructor Theory” av Wei (David) Wang.  Som fysiker finner jeg koblingene mellom software og fysikk interessante, dog ganske abstrakte.  Dette var en av få talks som nevnte noe om AI og så på hvilken rolle AI kunne spille i et prosjekt til f.eks. «Eventstorming» og til å understøtte arbeid i ulike faser.

Det ble brukt en isfjell-metafor, AI kunne hjelpe med det som stikker over overflaten – det eksterne, mens det fortsatt i stor grad vil være behov for menneskelige resursser - «internalization and socialization is still the key.»

Kl. 15.30 - Blue Room

“DDD and FP Can’t Be Friends – Yet” av Mike Sperber og Henning Schwentner så på hvordan et problem kan løses med ulike tilnærminger i Java og F#.  Ja, man løser ting på forskjellig måte i disse to språkene.  Kort og konsist i F#, mer ordrikt og med tester i forkant i Java.

Kl. 17.00 - Red Room

Konferansen ble avrundet med en talk av Kent Beck: ”Tidy First? A Daily Practice of Empirical Software Design”.  Kent Beck er helt rå som foredragsholder.  Han snakket også om kobling, og hvordan han de siste 15 årene hadde grunnet over hvordan kobling kunne være bra («high cohesion») og dårlig på en gang.  Han pekte på at den største kostnaden ved et system er knyttet til endringer og at endringskostnaden igjen henger sammen med kostnader knyttet til koblinger og kostnader knyttet til å løse opp i koblinger («decoupling»).  Kent Beck kommer med en bok om dette snart.

Han snakket litt filosofisk og praktisk om softwareutvikling og teamarbeid. Og på spørsmålet om man bør rydde først, og om det var greit å implementere noe på en bestemt måte, så var svaret naturligvis: «It depends.»