1. "bra" kod och "supple design"
Domain-Driven Design (DDD) är ett försök att beskriva vad "bra" kod är och hur man kan få projektet som helhet att behålla livsgnistan. Följande citat är hämtat från boken Domain-Driven Design och är typiskt för just DDD:
- "The heart of software is its ability to solve domain-related problems for its user. All other features, vital though they may be, support this basic purpose."
Detta citat relaterar till frågan om "bra" och "dålig" mjukvara. Vad är det då som särksiljer bra kod från dålig? När man tänker på det är det inte så lätt att peka ut exakt vad det är som gör koden "bra". Först måste man vet vad man menar med "bra":
- En enkel definition på "bra" är om koden är buggfri, alltså att koden på ett korrekt sätt implementerar de funktionella kraven.
Att koden är buggfri är ofta ett nödvändigt men inte tillräckligt krav för de flesta organisationer. De flesta organisationer kräver även att programmerare ska kunna förstå och även vidareutveckla koden.
- Den term som används för denna typ av kvalitet i DDD är supple design (supple=böjlig, smidig, spänstig, elastisk). En tyngre definition på denna term ges längre ner på denna sida.
2. Kärnbudskapet i DDD
Jag tycker man kan sammanfatta kärnbudskapet i DDD på följande sätt:
- Mjukvara är "bra" mjukvara om den innehar "supple design". Detta är den viktigaste egenskapen, till och med viktigare än att koden är funktionellt korrekt, eftersom nästan alla organisationer konstant utvecklas.
- Vägen till "supple design" är att namnge objekten i koden (klasser, metoder, tabeller) med termer tagna från gruppens gemensamma språk ("ubiquitous language" se nedan).
3. Webbresurser
Det finns två webbplatser som mer eller mindre drivs av Eric Evans:
4. Allmänna definitioner: Domän och modell
Nedan följer några grundläggade definitioner:
- Domain (domän): Ett område av kunskap, inflytande eller aktivitet. Det område på vilket en användare utnyttjar ett program är domänen för mjukvaran.
- Domain expert (domänexpert): Organisationens expert inom domänområdet. Domänexperten är inte en vanlig användare av mjukvaran utan en person med djup kunskap om domänen.
- Model (modell): Ett system av abstraktioner som beskriver valda delar av en domän och kan användas för att lösa problem relaterade till den domänen.
- Context (sammanhang, miljö): Den miljö som bestämmer ett ords betydelse.
5. Definitioner specifika för DDD
Följande definitioner är specifika för DDD. Definitionerna är tagna ur boken "glossary"-avsnitt:
- Ubiquitous language (överallt förekommande språk): Ett språk strukturerat kring en domänmodell och som används av all medlemmar i gruppen för att koppla alla gruppens aktiviteter med mjukvaran.
- Supple design (flexibel design): En design som sätter den inneboende kraften i en djupgående modell i händerna på en klientutvecklare, så att denne kan utföra klara, flexibla uttryck som ger förväntade resultat på ett robust sätt. Lika viktigt är att den tvingar samma djupa modell att göra själva deignen lätt för implementatören att forma och omforma så att den anpassas efter nya insikter.
- Bounded Context (bundet sammanhang, miljö): Den avgränsade applicerbarheten av en viss modell inom organisationen. Bounded Context ska visa var den egna modellen slutar gälla och där alltså en annan modell tar över. Ett Bounded Context har explicita gränser i termer av gruppens organisation, användning inom applikationen och fysisk manifestation som t.ex. databas schema el. likn. Bounded Context ger gruppens medlemmar en ren förståelse för vad som ska vara konsistent och vad som kan utvecklas oberoende.
- Context Map (sammanhangskarta): En karta över flera "Bounded Contexts" och deras inbördes relationer.
- Core Domain (kärndomän): En distinkt del av modellen, central för användarens mål, som diffrentierar applikationen och gör den värdefull.
- Distillation (destillering): Abstraktion av nyckelaspekter i en modell, eller uppdelning av ett större system för att få fram kärndomänen.
6. Sammanfattning av DDD
För att projektet ska behålla livsgnistan och flexibiliteten bör man enligt DDD göra följande:
- Bind modellen till implementationen: Det är den intima relationen mellan modellen och implementationen som gör modellen värdefull och som garanterar att analysen som ligger lagrad i modellen verkligen används i det färdiga programmet. Framförallt är det intima förhållandet viktigt för vidareutveckling av systemet.
- Bygg ett språk baserat på modellen (the ubiquitous language): Både domänexperter och programmerare förstår och använder termer från modellen.
- Utveckla en modell rik på kunskap (knowledge-rich model): Objekten i modellen bör innehålla regler, de ska inte vara endast datatyper.
- Destillera modellen: Nya begrepp läggs till när modellen utvecklas, men lika viktigt är att begrepp som inte används längre (eller av någon anledning inte längre passar in) tas bort. Ett oanvändbart begrepp som är bundet ett begrepp som vi vill behålla kan tas bort genom att en ny modell skapas där den gamla termin inte finns med.
- Experimentera och brainstorma: Genom att anamma en experimenterande mentalitet kan man vända och vrida på språket och modellen. Bara genom att prata sig igenom olika scenarion med hjälp av termerna i modellen kan man upptäcka ologiskta situationer.
