Den lilla tid jag har fått över de senaste dagarna har i stort sett gått till att läsa i den alldeles eminenta boken Implementing Domain-Driven Design. Boken bygger på sätt och vis vidare på Evans tidlösa bok genom att ta upp nya insikter som har framkommit samt hur DDD kan implementeras med modern teknologi. Den är en rejäl bok att sätta tänderna i och det vore att skryta om jag sa att jag har kommit halvvägs. Hittills har den bjudit på många handfasta tips på hur man ska förhålla sig till DDD rent praktiskt. Redan såhär långt har flera av mina frågetecken kring DDD rätats ut och fler lär det bli om boken fortsätter att leverera. Tidigare idag när jag bläddrade i ett kapitel om arkitekturer sprang jag på något som inte direkt är relaterat till DDD men som ändå var värdefullt för mig. Detta tänker jag skriva av mig om här och nu.

När jag sitter och hackar i mina hemmaprojekt brukar jag nog tänka på strukturen som en layered architecture (i brist på en vettig svensk benämning). I denna ”klassiker” ser man arkitekturellt på systemet i flera lager där varje lager endast känner till det lager som finns direkt under lagret i fråga (Figur 1). Alltså känner bara Domain layer i Figur 1 till Infrastructure layer. Nu brukar man inte vara så bokstavstrogen – som jag har förstått det är det vanligast att ett lager känner till samtliga underliggande lager. Denna form av layered architecture kallar man för relaxed.

Samtidigt har jag som förmodligen alla andra Javautvecklare under många år ägnat mig åt Dependency Injection (DI), i mitt fall via Spring. Att utveckla mot abstraktioner när det gäller saker som till exempel persistering sitter så i märgen på mig att jag knappt inte skulle kunna tänka mig att utveckla på något annat vis. DI är ett av flera sätt att realisera något som kallas för Dependency Inversion Principle (DIP). Väldigt förenklat kan man säga att principen innebär att man vänder på beroenderiktningen, att högnivåkomponenter inte är beroende av infrastrukturella saker. Detta rimmar illa med vad vi ser i Figur 1; enligt den traditionella layered architecture känner alla lager till Infrastructure layer. I alla fall om man tänker på varianten relaxed.

Som boken föreslår behöver vi om vi praktiserar DIP revidera Figur 1 för att bilden ska stämma med verkligheten. Jag låter mig här bli skamlöst inspirerad och min version av denna reviderade layered architecture kan ses i Figur 2. Den enda egentliga skillnaden mot innan är att Infrastructure layer nu finns att finna överst. Rent grafiskt kan man tycka att skillnaden är liten men konsekvensen av förändringen är stor. Figuren säger att det är okej för infrastrukturkomponenter att känna till abstraktioner (dvs gränssnitt) i till exempel applikations- och domänlagret. I verkligheten är det ju så vi hela tiden har arbetat med DI, att vi implementerar gränssnitt och dessa implementationer injectas in i programmet med hjälp av ramverk såsom Spring. Men den verkligheten stämmer inte överens med Figur 1.

För mig var det en ögonöppnare. Nu förstår jag varför jag har haft svårt att hitta en naturlig plats för infrastrukturklasser (tänk till exempel en HibernateAnimalRepository) i mina projekt. Den faktiska arkitekturen (Figur 2) matchade inte min mentala bild (Figur 1).