Domändriven design (mindre ofta domändriven design , DDD) är en uppsättning principer och scheman som syftar till att skapa optimala system av objekt. Det handlar om att skapa mjukvaruabstraktioner som kallas domänmodeller . Dessa modeller inkluderar affärslogik som upprättar en koppling mellan de faktiska förhållandena för produktapplikationsområdet och koden.
Domändriven design är inte en specifik teknik eller metodik. DDD är en uppsättning regler som gör att du kan fatta rätt designbeslut. Detta tillvägagångssätt låter dig avsevärt påskynda processen för mjukvarudesign inom ett okänt ämnesområde.
DDD-metoden är särskilt användbar i situationer där utvecklaren inte är expert på området för produkten som utvecklas. Till exempel: en programmerare kan inte känna till alla områden där programvara behöver skapas , men med rätt representation av strukturen, genom ett domänorienterat tillvägagångssätt, kan han enkelt designa en applikation baserad på nyckelpunkter och kunskap om arbetsområdet .
Denna term introducerades först av E. Evans i hans bok med samma namn "Domain-Driven Design" [1] .
Helst när man designar vill man ha en enda modell som fullständigt beskriver hela ämnesområdet, men i verkligheten, för att förenkla produktutvecklingsprocessen, presenteras domänen som en kombination av flera sammanhängande modeller.
Ett applikationsarkitekturdiagram är en beskrivning av en eller flera domänmodeller och deras relationer till varandra.
Användning av flera modeller på olika nivåer i projektet . Detta tillvägagångssätt används för att minska de olika relationerna mellan modeller, vilket eliminerar komplexiteten och krångligheterna i koden . Ibland är det oklart i vilket sammanhang modellen ska användas.
Lösning: Definiera exakt i vilket sammanhang modellen används. Bestäm gränserna för användningen av denna modell och dess egenskaper.
När ett stort antal personer arbetar med ett projekt finns det en tendens att dela upp modellen i flera mindre fragment. Ju fler människor, desto mer betydande är detta problem. I slutändan går projektets integritet förlorad.
Lösning: Kombinera ständigt bitar av kod från olika utvecklare och verifiera funktionalitet genom att testa . Detta gör att alla utvecklare kan stanna i ett stort koncept.
När man arbetar med flera separata modeller i en stor grupp kanske olika teammedlemmar inte är medvetna om enheterna i andra modeller, vilket komplicerar den övergripande monteringsprocessen av slutprodukten.
Lösning: Under designfasen, definiera exakt vad varje modell gör och hur den förhåller sig till andra modeller. I slutändan bör du sluta med en modellrelationskarta.
Vid design utifrån ett domänorienterat tillvägagångssätt används följande begrepp:
De flesta system för företag använder storskaliga ansvarsområden. I DDD kallas denna högsta organisationsnivå för det avgränsade sammanhanget. Till exempel kan faktureringssystemet för ett stort telekommunikationsföretag ha följande nyckelelement:
Alla ovanstående element måste inkluderas i ett enda, oavbrutet system. Vid design framstår aviseringssystemet och säkerhetssystemet som helt olika saker. System där implementeringen misslyckas med att separera och isolera avgränsade sammanhang får ofta en arkitektonisk stil som är passande namnet " Big Mudball " 1999 av Brian Foot och Joseph Yoder. [2]
Kärnan i domänspecifik design är den specifika definitionen av sammanhang och begränsningen av modellering inom dem.
Det enklaste sättet att uttrycka enheter är som substantiv : människor, platser, produkter, etc. Entiteter har både en personlighet och en livscykel. Vid designtid bör du tänka på enheter som beteendeenheter snarare än enheter av data. Oftast måste någon operation som du försöker lägga till i modellen tas emot av någon enhet, eller så börjar en ny enhet skapas eller hämtas. I mer löst kopplad kod kan du hitta många verktyg eller kontrollklasser som kontrollerar enheter utifrån.
Ett värdeobjekt är en egenskap som är viktig i den domän du modellerar. De, till skillnad från enheter, har ingen beteckning; de beskriver helt enkelt konkreta enheter som redan har beteckningar. Nyttan med värdeobjekt är att de beskriver entiteters egenskaper på ett mycket mer elegant och avsiktligt sätt. Det är alltid värt att komma ihåg att värdet på ett objekt aldrig ändras under körningen av hela programkoden . När den väl har skapats kan ändringar inte göras.
Ett aggregat är en speciell enhet som konsumenterna kommer åt direkt. Användningen av aggregat gör att du kan undvika överdriven anslutning av objekten som utgör modellen. Detta undviker förvirring och förenklar strukturen, eftersom det inte tillåter skapandet av tätt kopplade system.
Ibland finns det operationer eller processer i en domän som inte har någon beteckning eller livscykel. Domäntjänster tillhandahåller ett verktyg för att modellera dessa koncept. De är statslösa och starkt kopplade, ofta tillhandahåller en enda offentlig metod och ibland en överbelastning för fastställda operationer. Om flera beroenden ingår i ett beteende och det inte finns något sätt att hitta en lämplig plats i entiteten för att vara värd för det beteendet, används en tjänst. Även om själva termen "tjänst" är överbelastad med olika betydelser i utvecklingsvärlden, men i detta ämne betyder det en liten klass som inte representerar en specifik person, plats eller sak i applikationen som designas, utan innehåller någon form av processer . Användningen av tjänster låter dig ange en flerskiktsarkitektur , samt integrera flera modeller, vilket introducerar beroende av infrastrukturen. [3]
Även om i konceptet bör domänorienterad design inte begränsas till några representationer, men i praktiken används styrkorna hos objektorienterad programmering . Detta är användningen av arv , inkapsling , representation som metoder och klasser. Man måste komma ihåg att det domänspecifika tillvägagångssättet inte bara kan tillämpas på OOP-språk som Java , C# eller C++ , utan också på funktionella språk som F# , Erlang . Särskilt användbara är språk som stödjer skapandet och användningen av sina egna domänspecifika språk , som Scala (se även LOP ).
| Mjukvaruutveckling | |
|---|---|
| Bearbeta | |
Koncept på hög nivå | |
| Vägbeskrivning |
|
| Utvecklingsmetoder _ | |
| Modeller |
|
| Anmärkningsvärda siffror |
|