I Eric Evans bibel om Domain Driven Design skriver han "any object internal to an aggregate is prohibited from access except by traversal from the root". Det vil altså sige at man skal have et repository pr aggregate root, og at interne objekter kun må tilgås via navigation for at sikre indkapsling. Derudover må externe objekter kun må holde referencer til rooten og transient references til value objekter.

Kunsten ved at designe sine repositories på den måde er at få defineret sine aggregate roots rigtigt. Laver man et design hvor man anser en klasse som værende en del af en aggregate, og man senere erfarer at der skal kunne søges på properties på objektet og vises lister af dem, vil det kræve en refaktorering, da denne nu må være root.

Nogen typer systemer er karaktaristiske ved at næsten alle klasser kan ses som lister og er søgbare - i den typer systemer vil repository designet begynde at ligne en en-til-en mapning med de tabeller man har i databasen. Man kan imidlertid argumentere for at så længe det forhold opstår af den årsag er det ikke symptom på at designet er databasedrevet, men blot den naturlige måde at designe systemet på. Service orienterede løsninger vil som eksempel i mange tilfælde fungere naturligt på den måde.

Personligt kan jeg godt lide DDD måden at tænke repositories på, da det sikrer indkapsling og lægger op til at persistence ignorence ved at man undgår at repositories blot afspejler databasestrukturen. Dog vil jeg understrege ordet principper - da disse ofte er til for at blive brudt.

Jeg er jævnligt løbet på systemer hvor granuleringen af klasser og metoder bliver unaturligt hvis man følger fremgangen slavisk. Her kan det eksempelvis være en mulighed at lade repositories have metoder til at søge efter objekter der er interne i en aggregate - selvom det bryder direkte med ovennævnte principper.

Andre gange kan det virke helt naturligt at anskue dataaccess som mapning af tabeller - både fordi den teknologi man anvender til dataaccess låner sig bedre til det, og i systemer der af natur er meget datadrevne. RAD og udvikling af prototyper kan også i sig selv som princip være en modsætning, da det at designe repositories omkring aggregates kræver mere designmæssigt omhu.

Repositories er omdrejningspunktet i de fleste webapplikationer, og et godt repository design er derfor vigtigt. Jeg tror de fleste har prøvet at fortryde et designvalg i forhold til repositories og tænkt “why didn’t I take the blue pill”.

Da jeg startede som udvikler lærte jeg, ligesom så mange andre, at bygge et dataaccess lag hvor man typisk havde en klasse der håndterede adgang til en enkelt tabel i databasen. Det betød at database designet leakede ud i hele applikationen som blev databasedrevet. Sidenhen er ORM’s og DDD blevet mere udbredt og PI (Persistence Ignorance) tilstrebes. Samtidig er LINQ blevet den foretrukne måde at udtrykke querys på, hvilket giver en række nye design muligheder/beslutninger.

Derudover er der forskellige “skoler” med hensyn til om man mener querys bør indkapsles i et repository, eller om de skal ses som en del af ens business logic, og måske ligefrem være fuldgyldige objekter. Transaktioner og validering har desuden stor indflydelse på hvordan det kan være hensigtsmæssigt at designe sit repository - og hvordan det samlede design har indvirkning på hvordan applikationen struktureres.

For nylig læste jeg så en række blogposts der kan findes via CodeBetter’s “Reposptiry is dead: Long live repository”, hvor der netop blev diskuteret repository design, hvilket fik mig til også at tænke en ekstra gang over designet i mit nuværende projekt. Med udgangspunkt i de ting vil jeg derfor skrive en lille serie posts om emnet, hvor jeg i vilkårlig rækkefølge vil se på emner som:

• DDD principper
• Object-Relational Mappers
• Repositories som singletons
• Querying: fleksibilitet og indkapsling

Hvis Jokerens liv er et Junkiegøglercirkusliv må jeg betegne mit nye liv som et pendlerscrumagileliv. (Be warned: det her er en af de lidt bløde artikler om mig selv, og mine erfaringer - sorry).

Fra årsskiftet begyndte jeg at arbejde hos Vertica i Århus, men er stadig bosiddende i Odense. Det at skulle pendle var jeg spændt på da jeg tog imod jobbet, men det har vist sig ikke at være så hårdt som jeg kunne have frygtet. Jeg er som de fleste andre ikke voldsomt imponeret over DSB's planlægningsevner, og oplever dermed fra tid til anden lidt frustrationer. Alt i alt har det alligevel været rimeligt problemfrit at skulle pendle. Det skal siges at jeg ikke pendler hver dag, og arbejder i toget når jeg gør - hvilket naturligtvis også hjælper en del.

Udover at skulle tilpasse mig livet som pendler var det også et skifte til en virksomhed der i langt højere grad arbejder med scrum og agile principper. Det har betydet en noget anden arbejdsgang end jeg var vant til, og jeg må helt klart tilskrive mig den voksende skare af folk der tilslutter sig disse principper.

Scrum har været med til at gøre det lettere at fokusere på det der er jobbet - at skrive software - samtidig med at det giver en dejlig ærlig tilgang til tingene. De gevinster føler jeg allerede i hverdagen, selvom vi ikke selv mener at vi er færdige med at indføre scrum - og bliver man egentlig nogensinde bliver det? Jeg har været til JAOO days om agile udvikling i København, og vores projektledere har er blevet certificerede scrum mastere. Så det er et område vi har fokus på, og det er derfor rart at mærke at investeringen giver afkast - i modsætning til de fleste andre investeringer, som verden ser ud for tiden.

Til den mere tekniske side har jeg haft mere fokus på TDD, DDD og CI - som man ikke kommer udenom som moderne agile udvikler. Uden at være modstander  har jeg altid været lidt skeptisk overfor TDD, men jeg må erkende at jeg er begyndt at mærke gevinsten i form af bedre design, og følelsen af frihed til at refaktorere. Vi holdt codecamp i ANUG regi i starten af marts ved min kollega Daniel Gonzáles Garcia, og det virker til at være et emne der har rimelig stor interesse i communitiet. Forhåbentligt lokker det flere til at begynde at arbejde med frameworks som ASP.NET MVC - som jeg selv er igang med :)

DDD tankegangen har altid været det der faldt mig naturligt, kontra databasetænkning som har en tendens til at bide en i røven når et system bliver tilstrækkeligt omfattende - og dermed uoverskueligt. At vi direkte har fokus på principperne giver en god fælles terminologi, og kombineret med brugen af et ORM gør det livet som udvikler en del sjovere.

CI er for mig noget nyt at skulle bruge i praksis, og én umiddelbar erfaring har været at det fjerner en hel del af smerten ved at skulle udgive webløsninger. Det meste der skrives om CI handler om at få afprøvet den samlede kodebase, og få afviklet sine unittests. Dette er naturligt også et hovedfokus - men det at gøre udgivelse til en mere naturlig del af processen skal bestemt ikke overses som en vigtig gevinst.