Applying Domain-Driven Design and Patterns

Domain-Driven Design (DDD) är en design- och utvecklingsmetodik som det talas mer och mer om. Eric Evans, den mest namnkunnige DDD-förespråkaren tillika författaren till "Domain-Driven Design: Tackling Complexity in the Heart of Software", sammanfattar DDD på följande vis:

Fundamentally, DDD is the principle that we should be focusing on the deep issues of the domain our users are engaged in, that the best part of our minds should be devoted to understanding that domain, and collaborating with experts in that domain to wrestle it into a conceptual form that we can use to build powerful, flexible software. ("Eric Evans on why DDD Matters Today", http://www.infoq.com/)

I praktiken handlar det mycket om gammal hederlig objektorienterad design och analys, fokus på en renodlad domän-/verksamhetsmodell och verksamhetslogik (innebär ofta att någon sorts O/R-mapper används för att slippa lägga onödig tid och energi på dataaccess/persitering) och betoning av ett så kallat "ubiquitous language" (allestädes närvarande språk), d.v.s. ett gemensamt språk för, och en god kontinuerlig dialog mellan, verksamhet och utvecklingsprojekt. För läsare av den här bloggen kanske det bör tilläggas att DDD huvudsakligen har sina rötter i Java-världen, men metodiken är på frammarsch i .NET-världen också.

Jimmy Nilsson är en svensk utvecklare och Microsoft Most Valuable Professional (MVP) inom Solutions Architecture som tillsammans med Eric Evans och kanadensiskan Ying Hu driver domaindrivendesign.org. För ett halvår sedan utkom han med boken "Applying Domain-Driven Design and Patterns: With Examples in C# and .NET" (ADDDP; utgiven av Addison-Wesley, 2006).

Jimmy Nilssons bok handlar förstås till stor del om DDD, men en hel del andra intressanta ämnen konkurrerar om utrymmet bland bokens ca 500 sidor. Bland dessa ämnen framträder Test Driven Development (TDD) med refactoring, design patterns och O/R-mapping (med NHibernate) som de mest centrala och för framställningen genomgående. Andra ämnen som tas upp till behandling är bl.a. Service Oriented Architecture (SOA), Aspect Oriented Programming (AOP) med Spring.NET och hur man utvecklar testbara gränssnitt.

Bokens titel gör klart att den handlar om tillämpning av DDD och detta är ett löfte som infrias. Efter att i bokens första del av fem ha tecknat en bakgrund med beskrivningar av DDD, Design patterns och TDD, som redan den karakteriseras av många exempel, kastar sig Nilsson i den andra delen över ett exempelprojekt i form av en kort och koncis, men inte alls okomplicerad, kravlista. I tämligen detaljerade kodexempel visar han steg för steg hur man kan använda sig av TDD för att ta fram och förfina sin domänmodell och hur man kan hålla den fri från beroenden till exempelvis databas/persistering.

Just renodlingen av modellen och önskan att hålla isär den från annan kod för att verkligen kunna fokusera på domänproblemen är grundläggande i DDD och därmed också ett skäl till att O/R-mappers är så populära inom denna metodik, så även i ADDDP varför en icke föraktlig del (den tredje) av boken som sagt handlar om detta. Nilsson, med en stadig bakgrund inom databasutveckling, vrider och vänder på för- och nackdelarna med O/R-mappers, vilka kriterierna för en bra O/R-mapper är och slutligen hur exemplet NHibernate kan användas tillsammans med den domänmodell vi tillsammans - ja, det känns nästan så! - tagit fram under bokens gång.

Det märks att författaren har stor erfarenhet av såväl utvecklings- som verksamhetsproblematik och det är uppfriskande att se Nilsson söka upp de problemställningar som så ofta förekommer i verkliga projekt, men är ack så sällsynta i de många tillrättalagda handledningar man kan hitta i dokumentation och exempel på Internet, såväl från Microsoft som från andra, eller i andra böcker för den delen.

Bokens näst sista del handlar om "other design techniques to keep an eye on and start using" (med några av de tidigare nämnda ämnena så som SOA och AOP) och den sista är ett appendix med exempel på hur andra tillfrågade utvecklare skulle ha löst samma kravlista som Nilsson löst på sitt sätt i resten av boken. Båda dessa delar är nästan uteslutande författade av gästskribenter (bl.a. bloggarna Udi Dahan och Mats Helander). Några av dessa skribenter - och ytterligare ett par där till - har dessutom skrivit dels kortare texter, dels små noter inskjutna lite här och där i hela Nilssons framställning.

Jimmy Nilssons stil är en "prövande" stil, som på sätt och vis liknar den programmeringsstil han förordar, med många frågor, försök till lösningar, nya frågor och "refactoring" av de tidigare svaren. Lägg till detta en mycket ödmjuk hållning i övrigt och stilen blir stundtals för prövande och osäker med ständiga reservationer och försäkringar om att det ena eller andra inte är "the silver bullet". Samtidigt är det också denna stil som involverar läsaren och ger en inblick i hur en duktig utvecklare går till väga för att lösa ett problem, ja till och med en känsla för hur han tänker. Ett större problem blir det dock i kombination med gästtexterna, de insprängda noterna och bokens bredd av ämnen; det blir helt enkelt lite väl osammanhållet och spretigt ibland, vissa avsnitt känns malplacerade, t.e.x Udi Dahans annars intressanta text om SOA och den del av boken som handlar om designtekniker att hålla ett öga på kanske borde ha hamnat i bokens appendix istället för kapitlet med alternativa lösningsförslag.

På det stora hela utgör dessa problem dock inga avgörande invändningar mot Jimmy Nilssons bok som utan tvekan är mycket läsvärd. För den som likt jag är intresserad av, men ännu inte sysslat så mycket med, TDD och O/R-mappers är bokens praktiska orientering en guldgruva och en inspirationskälla till att äntligen komma igång.