Domænedrevet design (mindre ofte domænedrevet design , DDD) er et sæt principper og skemaer, der sigter mod at skabe optimale systemer af objekter. Det går ud på at skabe softwareabstraktioner kaldet domænemodeller . Disse modeller inkluderer forretningslogik, der etablerer en sammenhæng mellem de faktiske forhold for produktets anvendelsesområde og koden.
Domænedrevet design er ikke en specifik teknologi eller metode. DDD er et sæt regler, der giver dig mulighed for at træffe de rigtige designbeslutninger. Denne tilgang giver dig mulighed for betydeligt at fremskynde processen med softwaredesign i et ukendt emneområde.
DDD-tilgangen er især nyttig i situationer, hvor udvikleren ikke er ekspert inden for det produkt, der udvikles. For eksempel: En programmør kan ikke kende alle områder, hvor software skal oprettes , men med den rigtige repræsentation af strukturen, gennem en domæneorienteret tilgang, kan han nemt designe en applikation baseret på nøglepunkter og viden om arbejdsområdet .
Dette udtryk blev først introduceret af E. Evans i hans bog af samme navn "Domain-Driven Design" [1] .
Ideelt set vil man, når man designer, have en enkelt model, der fuldt ud beskriver hele fagområdet, men i virkeligheden, for at forenkle produktudviklingsprocessen, præsenteres domænet som en kombination af flere indbyrdes forbundne modeller.
Et applikationsarkitekturdiagram er en beskrivelse af en eller flere domænemodeller og deres relationer til hinanden.
Brug af flere modeller på forskellige niveauer af projektet . Denne tilgang bruges til at reducere de forskellige relationer mellem modeller, hvilket eliminerer kompleksiteten og forviklingerne i koden . Nogle gange er det ikke klart, i hvilken sammenhæng modellen skal bruges.
Løsning: Definer præcis den kontekst, som modellen bruges i. Bestem grænserne for brugen af denne model og dens egenskaber.
Når et stort antal mennesker arbejder på et projekt, er der en tendens til at dele modellen op i flere mindre fragmenter. Jo flere mennesker, jo større er dette problem. I sidste ende går projektets integritet tabt.
Løsning: Konstant at kombinere stykker kode fra forskellige udviklere og verificere funktionalitet gennem test . Dette giver alle udviklere mulighed for at blive i ét stort koncept.
Når du arbejder på flere separate modeller i en stor gruppe, er forskellige teammedlemmer muligvis ikke opmærksomme på entiteterne i andre modeller, hvilket komplicerer den overordnede monteringsproces af det endelige produkt.
Løsning: Under designfasen skal du definere præcis, hvad hver model gør, og hvordan den relaterer til andre modeller. I sidste ende bør du ende med et modelforholdskort.
Ved design baseret på en domæneorienteret tilgang anvendes følgende begreber:
De fleste systemer til virksomheder bruger store ansvarsområder. I DDD kaldes dette højeste niveau af organisation den afgrænsede kontekst. For eksempel kan et stort teleselskabs faktureringssystem have følgende nøgleelementer:
Alle ovenstående elementer skal indgå i et enkelt, uafbrudt system. Ved design skiller notifikationssystemet og sikkerhedssystemet sig ud som helt forskellige ting. Systemer, hvor implementering ikke formår at adskille og isolere afgrænsede sammenhænge, får ofte en arkitektonisk stil , der passende bliver kaldt " Big Mudball " i 1999 af Brian Foot og Joseph Yoder. [2]
Essensen af domænespecifikt design er den specifikke definition af kontekster og begrænsningen af modellering inden for dem.
Den nemmeste måde at udtrykke enheder på er som navneord : mennesker, steder, produkter osv. Enheder har både en personlighed og en livscyklus. På designtidspunktet bør du tænke på enheder som adfærdsenheder snarere end dataenheder. Oftest skal en handling, som du forsøger at tilføje til modellen, modtages af en enhed, eller en ny enhed begynder at blive oprettet eller hentet. I mere løst koblet kode kan du finde en masse hjælpe- eller kontrolklasser , der kontrollerer entiteter udefra.
Et værdiobjekt er en egenskab, der er vigtig i det domæne , du modellerer. De har, i modsætning til enheder, ingen betegnelse; de beskriver blot konkrete enheder, der allerede har betegnelser. Nytten af værdiobjekter er, at de beskriver entiteters egenskaber på en meget mere elegant og intentionel måde. Det er altid værd at huske på, at værdien af et objekt aldrig ændres under udførelsen af hele programkoden . Når først oprettet, kan der ikke foretages ændringer.
Et aggregat er en særlig enhed, som forbrugerne har direkte adgang til. Brugen af aggregater giver dig mulighed for at undgå overdreven forbindelse af de objekter, der udgør modellen. Dette undgår forvirring og forenkler strukturen, fordi det ikke tillader oprettelsen af tæt koblede systemer.
Nogle gange er der operationer eller processer i et domæne , som ikke har nogen betegnelse eller livscyklus. Domænetjenester giver et værktøj til modellering af disse koncepter. De er statsløse og stærkt koblede, og leverer ofte en enkelt offentlig metode og nogle gange en overbelastning for faste operationer. Hvis flere afhængigheder er inkluderet i en adfærd, og der ikke er nogen måde at finde et passende sted i enheden til at hoste den adfærd, så bruges en tjeneste. Selv om udtrykket "tjeneste" i sig selv er overbelastet med forskellige betydninger i udviklingsverdenen, men i dette emne betyder det en lille klasse , der ikke repræsenterer en bestemt person, sted eller ting i applikationen, der designes, men inkluderer en form for processer . Brugen af tjenester giver dig mulighed for at indtaste en flerlagsarkitektur , samt integrere flere modeller, hvilket introducerer afhængighed af infrastrukturen. [3]
Selvom i konceptet, bør domæneorienteret design ikke være begrænset til nogen repræsentationer, men i praksis bruges styrkerne ved objektorienteret programmering . Dette er brugen af arv , indkapsling , repræsentation som metoder og klasser. Det skal huskes, at den domænespecifikke tilgang ikke kun kan anvendes på OOP-sprog som Java , C# eller C++ , men også til funktionelle sprog som F# , Erlang . Særligt nyttige er sprog, der understøtter oprettelsen og brugen af deres egne domænespecifikke sprog , såsom Scala (se også LOP ).
| Softwareudvikling | |
|---|---|
| Behandle | |
Koncepter på højt niveau | |
| Vejbeskrivelse |
|
| Udviklingsmetoder _ | |
| Modeller | |
| Bemærkelsesværdige tal |
|