Domain-Driven-Design

Ressourcer:

• Bog: Domain-Driven-Design Distilled
• Kursus: Ambar kursus i Microservices
• Medium om DDD

Det gik op for mig i sidste uge, hvor vi talte DCD, at jeg manglede at tjekke op på metoder til modullering af microservices i en arkitekturmæssig forstand. Jeg havde godt forstået at microservices meget gerne skulle leve op til Single Responsibility Princippet, men samtidig kunne jeg godt mærke at jeg havde svært ved at afgrænse microservices og at fastsætte principperne for opdelingen. Jeg måtte lige tænke over det, sagde jeg til gruppen, som alle har valgt fagene UI/UX.
Jeg fik egentlig ikke kigget særlig meget på det. Jeg følte først jeg skulle have mere indsigt i hvorfor microservice-arkitekturens popularitet var så stor som den var.
I den forbindelse meldte jeg mig til et Ambar-kursus.
De lagde ud med at fortælle om hvorfor microservices' var fedt. Og derefter hvordan man typisk gik til værks i fht. at udforme en. Og her var underviseren stor fortaler for at gå til det med principperne for Domain-Driven-Design og opdele microservices ud fra bounded-contexts. Hvad faen' er bounded contexts? Måske det ville hjælpe hvis jeg læste op på Domain-Driven-Design (DDD).

Domain-Driven-Design (DDD) er et sæt af principper som man designer ud fra igennem en etableret proces. DDD blev introduceret i 2003 i bogen “Domain-Driven Design: Tackling Complexity in the Heart of Software” af Eric Evans. Det lægger som så mange andre design-tilgange vægt på en tæt kobling mellem forretnings/business/problemområdets lægmandstermer og en af de store fordele ved netop DDD i forbindelse med design af sin microservice-arkitektur er at processen afføder bounded contexts som er afgrænsede forretningsområder, domæner, sektioner og grunden til at DDD er blevet så populært er fordi disse bounded contexts, hvis lavet korrekt, kan identificere microservices. Man siger i flæng, at en bounded context hvis udvundet igennem DDD svarer til en microservice, som et hold så kan påtage sig ansvaret for videre at udforske domænet af, og arbejde på at udvikle, "afgrænset" fra andre bounded contexts. Dette lægger sig op af en de helt store fordele og grunde til valg adoptionen af microservice-arkitektur.

Hvorfor DDD?
En virksomheds domæne kan være yderst kompleks og bestå af mange sektioner. Tag f.eks. virksomheden Uber. Lad os sige at Uber har en masse kontorer som hver især har deres domæne at tage hånd om.

• Kontor for chauffører
• Kontor for anmeldelser
• Kontor for turarrangering
• Kontor for kundemodtagelse
• Kontor for økonomisk logistik
• Kontor for generel logistik

Alle disse kontorer kunne koges til en bounded context, hvor indenfor der eksisterer det man i DDD så fint kalder Ubiquitous Language , som er et indenfor konteksten anerkendt og gængst brugt sprog imellem de kontoransatte og dem for hvem kontoret er lavet. Der er ingen grund til at kontoret for økonomisk logistik skal vide særlig meget om hvad for et sprog der tales på kontoret for chauførrer, og at sørge for at holde kontoret for chauffører opdateret på alle ændringer der foretages i kontoret for økonomisk logistik, sprogopdatering, reformationer og optimering af arbejdsmetoder osv. Det er essentielt at man som udvikler forstår sig på "The Ubiqutious Language" indenfor domænet, så man i udviklingen af softwaren opretholder den tætte kobling mellem software og domænet hvor til softwaren udvikles som et brugsværktøj.

DDD-processen:
Strategisk Design og Taktisk Design.
De overordnede felter indenfor hver design-sti er:
Strategisk design: Opdeling af det overordnede system i mindre og mere håndterbare dele.

• Afklaring af Ubiquitous Language:
Etablering af fællessprog mellem udviklere og domæneeksperter (domæneekspert i ental i vores tilfælde). Efter en måned var der f.eks. stadig uklarheder omkring cerebral parese som... skavank. Hjerneskade? Spastiker? Spastisk lammelse? Sygdom? Diagnose?

• Afklaring af Bounded Contexts:
Tydelige grænser, hvor en specifik domænemodel gælder og hvorinden der er et fællessprog.
• Context Mapping:
En visuel repræsentation af, hvordan de forskellige Bounded Contexts hænger sammen og interagerer.

Taktisk design: Implementering af domænemodellen inden for en bounded context vha. centrale byggekloder:

• Entities:
Objekter med en unik identitet, der bevares over tid. I vores tilfælde f.eks. en patient med et specifikt patient-ID.
• Value Objects:
Identitetsløse objekter, der er defineret af deres attributter. I vores tilfælde f.eks. LoginRequest (username, password) og en JWT-token.
• Aggregate Root:
En samlet indgang til en gruppe relaterede entiteter og værdiobjekter. I vores eksempel er det f.eks. et dagbogsindlæg, som involverer patient, tilknyttet terapeut, dagbog og aktiviteter.
• Services:
Stateless operationer, der ikke naturligt passer til entiteter eller værdiobjekter. I vores eksempel er dette f.eks. en DiaryEntryService, som er en domæneoperation, der hjælper med at aggerere inputs fra patient og forberede disse til en persistering til databasen for vores Diary-microservice.
• Domain Events:
Hændelser, der repræsenterer vigtige ændringer i systemets tilstand. For eksempel kan en "PatientCreated"-hændelse udløse, at andre dele af systemet opdateres (som f.eks. oprettelse af dagbog og persistering af denne og sammenkædning med et userId fra PatientCreated), uden at de direkte afhænger af hinanden.

Og det var det jeg havde om DDD for denne gang. Vi skal nu i gruppen til at arbejde med netop denne designtilgang og der vil snarest blive lagt opslag op med hvordan vi gør og hvordan vi har gjort og måske også hvordan vi burde gøre i fremtiden.