Domänstyrd design



Internet är en outtömlig källa till kunskap, även när det gäller Domänstyrd design. Århundraden av mänsklig kunskap om Domänstyrd design har lagts och läggs fortfarande på nätet, och det är just därför som det är så svårt att få tillgång till det, eftersom det finns platser där det kan vara svårt eller till och med omöjligt att navigera. Vårt förslag är att du inte ska skeppsbrutet i ett hav av uppgifter om Domänstyrd design och att du snabbt och effektivt ska kunna nå alla visdomens hamnar.

Med detta mål i åtanke har vi gjort något som går utöver det uppenbara, nämligen att samla in den mest aktuella och bäst förklarade informationen om Domänstyrd design. Vi har också ordnat den på ett sätt som gör den lätt att läsa, med en minimalistisk och trevlig design som garanterar den bästa användarupplevelsen och den kortaste laddningstiden. Vi gör det enkelt för dig så att allt du behöver oroa dig för är att lära dig allt om Domänstyrd design! Så om du tycker att vi har uppnått vårt syfte och du redan vet vad du ville veta om Domänstyrd design, vill vi gärna ha dig tillbaka i sapientiasv.com:s lugna hav när din hunger efter kunskap väcks på nytt.

Domain-driven design ( DDD ) är en metod för att modellera komplex programvara . Modelleringsprogramvaran är därmed väsentligt från de som ska implementeras Fachlichkeiten den applikationsdomän som påverkas. Termen domänstyrd design myntades 2003 av Eric Evans i sin bok med samma namn.

beskrivning

Domänstyrd design är inte bara en teknik eller en metod. Snarare är det ett sätt att tänka och prioritera för att öka produktiviteten för mjukvaruprojekt i miljön i komplexa tekniska sammanhang. Domänstyrd design baseras på följande två antaganden:

  • Fokus för programvarudesignen är på det tekniska och den tekniska logiken.
  • Utformningen av komplexa tekniska relationer bör baseras på en modell av applikationsdomänen , domänmodellen.

Domänstyrd design är inte knuten till någon specifik mjukvaruutvecklingsprocess utan baseras på agil mjukvaruutveckling . I synnerhet kräver det iterativ mjukvaruutveckling och nära samarbete mellan utvecklare och experter på ämnen.

Syftet med all programvara är att stödja uppgifterna för en specifik applikationsdomän . För att kunna göra detta framgångsrikt måste programvaran harmoniskt matcha ämnet för applikationsdomänen som den är avsedd för. Domänstyrd design gör detta möjligt genom programvarumodellering av grundläggande begrepp och element i applikationsdomänen och deras relationer.

Arkitekturen kännetecknas av att det finns ett tydligt affärslogiklager. Detta lager ska koppla från domänklasserna från andra funktioner i systemet och göra dem så lätt igenkännliga som möjligt. Olika arkitektoniska stilar kan användas för att bädda in affärslogiklagret. Dessa inkluderar lagerarkitekturen och den sexkantiga arkitekturen.

I den domänstyrda designen innehåller klasserna i domänmodellen både data och hela funktionaliteten hos det ämne som ska implementeras, dvs. hela ämneslogiken. Ren dataklasser endast med åtkomstmetoder men utan teknisk funktion anses vara kodluktar . En domänmodell baserad på dataklasser kallas anemisk och anses därför vara en antipattern , eftersom den beskriver en domänmodell utan speciallogik.

Domänstyrd design står i kontrast till det mindre komplexa Smart UI- utvecklingsmönstret . När du använder Smart UI integreras applikationslogiken direkt i användargränssnittet. Det betyder att det inte finns något dedikerat lager för applikationslogik som kan återanvändas av olika komponenter.

Allestädes närvarande språk

Domänstyrd design baseras på ett antal koncept som bör beaktas vid modellering - men också i andra programvaruutvecklingsaktiviteter . Huvudfokus här är införandet av ett allestädes närvarande (vanligt förekommande, allestädes närvarande , allestädes närvarande ) språk som bör användas inom alla områden av programutveckling. Ett språk för beskrivning av de tekniska aspekterna, elementen i domänmodellen, klasserna och metoderna etc. Det definieras som:

"Ett språk strukturerat kring domänmodellen och används av alla teammedlemmar för att koppla alla aktiviteter i teamet med programvaran."

"Ett språk som är strukturerat kring applikationsdomänen och används av alla teammedlemmar för att länka alla teamaktiviteter med programvaran."

- Eric Evans : Presentationsmaterial från sitt föredrag den 6 november 2007 på JAOO

Domänstyrd design är i sig oberoende av programmeringsspråk, verktyg och ramar. Ändå finns det ett antal verktyg och ramar som erbjuder stöd för implementering av specifika DDD-mönster eller stöder DDDs strategi.

Komponenter i domänmodellen

Domänstyrd design skiljer mellan följande komponenter i domänmodellen:

Enheter ( enheter , referensobjekt )
Objekt av modellen som inte definieras av deras egenskaper utan av deras identitet. Till exempel kan en är personen brukar avbildas som en enhet. En person förblir därför densamma när deras egenskaper förändras; och de skiljer sig från en annan person, även om de har samma egenskaper. Enheter modelleras ofta med unika identifierare .
Värdeobjekt ( valueObjects )
Objekt av modellen som inte har eller behöver någon konceptuell identitet och definieras således enbart av deras egenskaper. Värdefulla föremål är vanligtvis modeller av oföränderliga föremål ( oföränderliga föremål ), så de är återanvändbara (se Flyweight ) och kan distribueras.
Aggregat ( aggregat )
Aggregat är kombinationer av enheter och värdeobjekt och deras associering med varandra för att bilda en gemensam transaktionsenhet. Aggregat definierar exakt en enhet som den enda åtkomsten till hela aggregatet. Alla andra enheter och värdeobjekt får inte statiskt refereras från utsidan. Detta garanterar att alla invarianter i aggregatet och de enskilda komponenterna i aggregatet kan säkerställas.
Föreningar ( föreningar )
Som definierat i UML är associeringar relationer mellan två eller flera objekt i domänmodellen. Här beaktas inte bara statiska förhållanden som definieras av referenser utan även dynamiska förhållanden som uppstår till exempel endast genom bearbetning av SQL-frågor.
Serviceobjekt ( tjänster )
I domänstyrd design modelleras funktionaliteter som representerar ett viktigt tekniskt begrepp och som konceptuellt hör till flera objekt i domänmodellen som oberoende tjänsteobjekt. Serviceobjekt är oftast statslösa och därför återanvändbara klasser utan föreningar, med metoder som motsvarar de funktioner som erbjuds. Dessa metoder tar emot de värdeobjekt och enheter som är nödvändiga för att bearbeta funktionaliteten.
Tekniska händelser ( domänhändelser )
Affärshändelser är objekt som beskriver komplexa, under vissa omständigheter dynamiskt förändrade, handlingar av domänmodellen som orsakar en eller flera åtgärder eller förändringar i affärsobjekten. Tekniska händelser möjliggör också modellering av distribuerade system. De enskilda delsystemen kommunicerar endast via tekniska händelser, vilket innebär att de frikopplas kraftigt och hela systemet är mer underhållbart och skalbart .
Moduler ( moduler , paket )
Moduler delar upp domänmodellen i funktionella (icke-tekniska) komponenter. De kännetecknas av stark inre sammanhållning och låg koppling mellan modulerna.

Domänstyrd design känner också till två andra komponenter i domänmodellen - fabriker och arkiv . Även om dessa inte implementerar affärsfunktionalitet själva, är de fortfarande en del av domänmodellen, eftersom de ger viktig funktionalitet för affärsobjektens livscykel.

Fabriker ( fabriker )
Fabriker tjänar till att lägga ut produktionen av specialobjekt till speciella fabriksobjekt. Detta är användbart om antingen generationen är komplex (och till exempel kräver associeringar som det tekniska objektet inte längre behöver) eller om det specifika skapandet av de tekniska objekten ska kunna utbytas vid körning. Fabriker implementeras vanligtvis genom att generera designmönster som abstrakt fabrik , fabriksmetod eller byggare .
Förvar
Förvar abstraherar uthållighet och sökning efter specialobjekt. Den tekniska infrastrukturen och alla åtkomstmekanismer till detta är separerade från affärslogiklagret med hjälp av förvar . För alla tekniska objekt som laddas via infrastrukturlagret tillhandahålls en förvarsklass som inkapslar laddnings- och sökteknologierna som används från utsidan. Förvaren själva är en del av domänmodellen och därmed en del av affärslogiklagret. De är de enda som får tillgång till objekten i infrastrukturlagret, som oftast implementeras med hjälp av designmönstret Data Access Objects , Query Objects eller Metadata Mapping Layers .

Namnen på klasserna i affärslogikskiktet som motsvarar dessa mönster är delar av det allestädes närvarande språket och bör namnges därefter. En ändring av namnet på ett tekniskt objekt genom refactoring motsvarar således en ändring av applikationens tekniska natur.

Fler tekniker

Domänstyrd design beskriver och rekommenderar ett antal andra tekniker och metoder för att implementera domänmodellen:

Arkitektoniska tekniker

Utvecklande struktur ( utvecklande ordning )
antar att stora strukturer i domänmodellen idealiskt bara uppstår över tiden eller utvecklas över tiden. Stora strukturer bör implementeras så enkelt som möjligt och med så få undantag som möjligt.
Systemmetafor ( systemmetafor )
är ett koncept från Extreme Programming , som underlättar kommunikationen mellan alla inblandade genom att beskriva systemet med en metafor, en vardaglig berättelse som liknar innehållet och är förståelig för alla parter. Detta bör passa så bra som möjligt och användas för att stärka det allestädes närvarande språket.
Ansvarsskikt ( ansvarsskikt )
är uppdelningen av domänmodellen i lager efter ansvar. Domänstyrd design föreslår följande lager: beslutsskikt, regellager, åtaganden, arbetsprocesser, potential.
Nivåkunskap ( kunskapsnivå )
beskriver den uttryckliga kunskapen om domänmodellen. Det är nödvändigt i situationer där beroenden och rollerna mellan enheterna varierar beroende på situationen. Kunskapsnivån bör innehålla dessa beroenden och roller på ett externt anpassningsbart sätt så att domänmodellen kan förbli specifik och utan onödiga beroenden.
Tilläggsramar ( pluggbart komponentramverk )
är tanken att ansluta olika system med varandra via ett komponentramverk.

Designtekniker

Intentions beskrivande gränssnitt ( avsiktsgränssnitt )
beteckna gränssnitt för klasser och komponenter som gör det möjligt för utvecklare att använda dem utan att behöva studera källkoden. Detta säkerställer att dessa klasser och komponenter används och underhålls i enlighet med deras avsikter.
Biverkningsfria funktioner ( biverkningsfria funktioner )
är metoder som inte påverkar status för en modul. Dessa är lättare att testa och bör därför föredras. De bör därför innehålla majoriteten av applikationslogiken. Metoder som ändrar tillståndet - så kallade kommandometoder - bör separeras från dem, hållas så enkla som möjligt och inte returnera några klasser av domänmodellen.
Påståenden
tjäna i domänstyrd design för att synliggöra biverkningar av kallade metoder utan att behöva studera källkoden Detta tillvägagångssätt - som ligger nära design enligt kontrakt - innebär att utvecklare kan förstå effekterna av de använda metoderna och därmed kan datakapsling endast användas korrekt.
Oberoende klasser ( fristående klasser )
är klasser som inte har något uttryckligt eller implicit beroende av andra klasser. De är lättare att förstå och bör därför sökas genom att eliminera alla onödiga beroende.
Konceptuella konturer ( konceptuella konturer )
beskriver begreppen som ligger till grund för designen. Dessa bör anpassas till de stabila aspekterna av ämnet genom successiv refactoring. Detta ökar sannolikheten för att framtida förändringar lättare kan implementeras med den befintliga designen.
Funktionella grader ( stängning av operationer )
i domänstyrd design är metoder vars returtyp är densamma som för deras argument eller attribut som används i metoden. Även om dessa metoder utökar möjligheterna för en klass, introducerar de inte några beroenden av andra begrepp. De är därför att föredra framför metoder vars andra typer introducerar.
Antikorruptionslager ( antikorruptionslager )
är ett arkitektoniskt lager som skiljer domänmodellen från andra modeller. Även en del av domänmodellen möjliggör antikorruptionsskiktet åtkomst till den externa modellen som krävs av den egna domänmodellen. De egna koncepten och språkelementen översätts till de i den utländska modellen, den egna domänmodellen påverkas inte av den främmande modellen. Detta implementeras mestadels med designmönster för fasad , adapter och överföringsobjekt .

Dessa och andra vanliga designtekniker för objektorientering leder till en deklarativ stil ( deklarativ stil ) av designen. Detta gör inte bara koden kortare, lättare att förstå och lättare att testa, utan gör det också möjligt att räkna ut kärnteknik och därmed koncentrera sig på relevanta tekniska funktioner i en programvara.

Procedurer

Dessutom definierar domänstyrd design en serie procedurer som tjänar till att garantera modellernas integritet. Detta är särskilt nödvändigt när flera team ska arbeta tillsammans under olika ledning och samordning inom olika ämnesområden, men i ett stort projekt.

Grafiken visar beroendet mellan dessa och andra element i domänstyrd design.

Vision om professionalism ( uttalande om domänvision )
är en kort beskrivning av visionen bakom kärnteknik och tillhörande mål. Den anger riktningen för utvecklingen av domänmodellen och fungerar som en länk mellan projektvisionen / systemmetaforen och detaljerna i kärnverksamheten och koden.
Kontextöversikt ( sammanhangskarta )
ger en omfattande översikt över alla modeller, deras gränser och gränssnitt. Som ett resultat växer kontexterna inte till områden i andra sammanhang, och kommunikationen mellan kontexterna sker via väldefinierade gränssnitt.
Kontextgränser ( begränsat sammanhang )
beskriva gränserna för varje sammanhang på en mängd olika sätt, såsom teamuppdrag, avsedd användning, underliggande databasscheman. Detta gör det tydligt var ett sammanhang tappar sin giltighet och ett annat sammanhang potentiellt tar sin plats.
Kernfachlichkeit ( kärndomän )
är den mest värdefulla delen av domänmodellen, den del som ger flest användarfördelar. De andra delarna av domänmodellen tjänar främst till att stödja kärnverksamheten och att berika den med mindre viktiga funktioner. Vid modellering bör särskild uppmärksamhet ägnas åt kärnteknik, och den bör implementeras av de bästa utvecklarna.
Split Core ( delad kärna )
är en del av ämnet som delas mellan olika delar av projektet. Detta är användbart om de olika projektdelarna bara är löst kopplade till varandra och projektet är för stort för att kunna implementeras i ett team. Den delade kärnan utvecklas gemensamt av alla projektteam som använder den. Detta kräver både mycket samordning och integrationsarbete.
Kund-leverantör ( kund-leverantör )
är metaforen för förhållandet mellan projektteam, där ett team implementerar en tekniskhet som det andra laget bygger på. Detta säkerställer att det beroende teamet stöds väl av implementeringsteamet, eftersom deras krav implementeras med samma prioritet som de faktiska kraven för leverantörsteamet.
Separerad kärna ( segregerad kärna )
hänvisar till övervägande att flytta kärnämnet, även om det är nära kopplat till stödjande modellelement, till en separat modul och minska kopplingen med andra moduler. Detta sparar kärnteknik från hög komplexitet och ökar underhållsförmågan.
Generiska sub-Fachlichkeiten ( generiska underdomäner )
beskriver tanken att lagra de delar av domänmodellen som inte tillhör kärnämnesområdet i form av modeller som är så generiska som möjligt i separata moduler. Eftersom de inte representerar kärnverksamheten och är generiska kan de utvecklas outsourcade eller ersättas med standardprogramvara.
Kontinuerlig integration ( kontinuerlig integration )
I domänstyrd design används den för att kontinuerligt integrera alla ändringar i en domänmodell med varandra och för att automatiskt kunna testa dem mot befintlig specialistkunskap.

Jämförelse med andra metoder och tekniker

Objektorienterad analys och design
Även om DDD teoretiskt inte är begränsad till objektorienterade begrepp, används i praktiken DDD främst för objektorienterad analys och design. Många av begreppen DDD bygger på paradigmer för objektorienterad mjukvaruutveckling. DDD kan således ses som en metod för objektorienterad analys och design.
Modelldriven mjukvaruutveckling och modelldriven arkitektur (MDA)
DDD är kompatibel med modelldriven programvaruutveckling men har olika avsikter. Modelldriven mjukvaruutveckling handlar mer om teknikerna för hur modeller kan implementeras i olika mjukvaruplattformar, medan DDD främst handlar om hur bättre domänmodeller kan uppnås. DDD är starkt beroende av en kontinuerligt utvecklad modell, som förbättras genom pågående refactoring , och vars implementering på mjukvaruplattformar kan stödjas av modelldriven mjukvaruutveckling.
Plain Old Java Objects (POJOs) och Plain Old CLR Objects (POCOs)
POJOs och POCOs är tekniska begrepp från Java och .NET . De bygger emellertid på den uppfattning som också sprids i DDD att tekniska objekt endast bör implementera krav på domänmodellens funktioner och inte teknikspecifika krav.
Nakna föremål
Nakna objekt är ett arkitekturmönster som, precis som DDD, antar att hela den tekniska logiken ska kartläggas i tekniska objekt. Dessutom sprider Naked Objects-arkitekturmönstret att användargränssnittet är en direkt representation av de tekniska objekten och därför ska genereras helt från de tekniska objekten - ett krav som DDD inte ställer.
Objektorienterad uthållighetsmekanism
Objektorienterade uthållighetsmekanismer, såsom objektrelationskartläggning eller objektdatabaser, handlar om utbyte av dataåtkomstskiktet under de tekniska objekten. De är därför ett synergetiskt tillskott till domänstyrd design, eftersom arkitekturen således är mer centrerad på specialobjekten.
Data Context Interaction (DCI)
Data Context Interaction är ett arkitekturmönster som kan komplettera komponenterna i domänmodellen för domänstyrd design (enheter, värdeobjekt, aggregat, serviceobjekt och affärshändelser) eller kan kompletteras av dem. Således kan dataobjekten för DCI förfinas av enheterna, värdeobjekten och aggregaten för DDD, kontextobjekt kan i sin tur representeras av serviceobjekt och affärshändelser. Rollerna för interaktioner mellan DCI utökar i sin tur komponenterna i den domänstyrda designen. Båda teknologierna kan därför ses som kompatibla och kompletterande med varandra.
Domänspecifikt språk (DSL)
Ett domänspecifikt språk (DSL) är ett formellt språk som är specifikt utformat och implementerat för ett specifikt problemområde ( problemdomänen ). DDD är inte i sig själv och kräver inte DSL för att kunna fungera.
Aspektorienterad programmering (AOP)
AOP är en teknik som gör det möjligt för DDD att skilja vissa, annars vanligtvis djupt sammanvävda tekniska aspekter (som loggning , säkerhet, transaktionshantering ) från domänmodellen. Detta gör det enkelt att uppfylla DDD: s krav på fullständig avskiljning av domänmodellen från resten av applikationen.
Verktygs- och materialinriktning (WAM)
WAM är en metod för mjukvaruutveckling som är inriktad på applikation och hög användningskvalitet och har många likheter med DDD. I synnerhet motsvarar "byggstenarna" från DDD till stor del designmetaforerna i WAM. En viktig idé med WAM är att överföra verktyg och material som en användare arbetar med i den verkliga världen till programvaran. De ska vara tillgängliga där för användaren, men också i koden.

litteratur

webb-länkar

Individuella bevis

  1. a b Eric Evans: Domain-Driven Design. Att hantera komplexitet i hjärtat av programvaran . Addison-Wesley, 2003, ISBN 978-0-321-12521-7 (engelska, dddcommunity.org ). dddcommunity.org ( Memento av den ursprungliga från 21 oktober, 2016 i Internet Archive ) Info: Den arkiv länk infördes automatiskt och har ännu inte kontrollerats. Kontrollera original- och arkivlänken enligt instruktionerna och ta bort detta meddelande.  @ 1@ 2Mall: Webachiv / IABot / dddcommunity.org
  2. Definition av DDD enligt dddcommunity.org
  3. Eric Evans: Domain-Driven Design . Att hantera komplexitet i hjärtat av programvaran. Addison-Wesley, 2003, ISBN 978-0-321-12521-7 , pp. xxii (engelska, http://dddcommunity.org/ ). http://dddcommunity.org/ ( Memento av den ursprungliga från 21 oktober 2016 i Internet Archive ) Info: Den arkiv länk infördes automatiskt och har ännu inte kontrollerats. Kontrollera original- och arkivlänken enligt instruktionerna och ta bort detta meddelande.  @ 1@ 2Mall: Webachiv / IABot / dddcommunity.org
  4. ^ Floyd Marinescu, Abel Avram: Domain-Driven Design snabbt . Lulu Press, 2006, ISBN 978-1-4116-0925-9 , kap. 1 , s. 4 (engelska, InfoQ: Domain Driven Design snabbt ).
  5. sexkantig arkitektur
  6. En introduktion till Domain Driven Design. I: www.methodsandtools.com. Hämtad 21 oktober 2016 .
  7. Anemisk domänmodell
  8. Presentation på JAOO den 6 november 2007 av Eric Evans, presentation på InfoQ
  9. Eric Evans: Vad jag har lärt mig om DDD sedan boken. (Video) Domain Language, Inc., maj 2009, nås den 23 oktober 2010 (engelska, diskussion om domänhändelserna från 13:00 till 28:05 Presentation inspelad vid DDD-NYC SIG, ursprungligen presenterad på QCon London 2009 ).
  10. Domänstyrd design snabbt, kapitel 5, s. 67ff
  11. ^ Dan Haywood: Domain-Driven Design using Naked Objects . Red.: Pragmatiska programmerare. Pragmatiska programmerare, 2009, ISBN 978-1-934356-44-9 (engelska, Domain-Driven Design using Naked Objects ).

Opiniones de nuestros usuarios

John Lundin

Det var ett tag sedan jag såg en artikel om _variabel skriven på ett så didaktiskt sätt. Jag gillar det.

Gudrun Bäckström

Jag trodde att jag redan visste allt om Domänstyrd design, men i den här artikeln har jag verifierat att vissa detaljer som jag tyckte var bra inte var så bra. Tack för informationen.

Sonja Lindblom

Jag behövde hitta något annorlunda om Domänstyrd design, vilket inte var det typiska som alltid läses på internet och jag gillade den här artikeln av Domänstyrd design.