DDD

Allikas: Teadmusbaas

Valdkonnapõhine (Domeen) disain (DDD)

Domain-driven design (DDD) on lähenemine tarkvaraarendusele keerukate vajaduste jaoks, ühendades selle rakendamise areneva mudelisse. Domeenipõhise disaini eeldus on järgmine:

  • paigutades projekti põhitähelepanu põhivaldkondade ja domeenikogumite loogikale;
  • domeeni mudeli keerukate disainilahenduste aluseks;
  • tehniliste ja domeeniekspertide vahelise loomingulise koostöö algatamine, et korrata kontseptuaalset mudelit, mis tegeleb konkreetsete domeeniprobleemidega.

Terminit kirjutas Eric Evans oma sama pealkirjaga raamatus.

Mõisted

Mudeli mõisted on järgmised:

  • Sisu

Seade, milles ilmub sõna või avaldus, mis määrab selle tähenduse;

  • Domeen

Teadmiste valdkond (ontoloogia), mõju või tegevus. Valdkond, kuhu kasutaja rakendab programmi, on tarkvara tsoon;

  • Mudel

Abstraktsioonide süsteem, mis kirjeldab domeeni valitud aspekte ja mida saab kasutada selle domeeniga seotud probleemide lahendamiseks;

  • Igakülgne keel

Keel on domeeni mudeli ümber struktureeritud ja seda kasutavad kõik meeskonna liikmed, et ühendada kogu meeskonna tegevused tarkvaraga.

Strateegiline domeenil põhinev disain

Ideaalis oleks eelistatav olla ühtne, ühtne mudel. Kuigi see on üllas eesmärk, tegelikult see tavaliselt killustatud mitu mudelit. Kasulik on tunnistada seda elukut ja töötada sellega.

Strateegiline disain on põhimõtete kogum, mis tagab mudeli terviklikkuse, domeenimudeli destilleerimise ja mitmete mudelitega töötamise.

Piiratud kontekst

Mitu mudelit on mängul ükskõik millises suurprojektis. Kuid kui erinevatest mudelitest lähtuv kood on kombineeritud, muutub tarkvara ebameeldivaks, ebausaldusväärseks ja raskesti mõistetavaks. Meeskonnaliikmete vaheline suhtlemine tekitab segadust. Sageli on ebaselge, millises kontekstis mudelit ei tuleks kohaldada.

Seetõttu: määratlege selgesõnaliselt kontekst, milles mudel kehtib. Selgesõnaliselt piiritletud meeskonna korralduse, kasutamise konkreetsetes rakendusvaldkondades ja füüsilised avaldumised nagu koodi alused ja andmebaasi skeemid. Hoidke mudelit nendes piirides rangelt järjepidevaks, kuid ärge muretsege ega segage väljastpoolt olevate probleemidega

Pidev integratsioon

Kui mitmed inimesed töötavad ühes ja samas piiratud kontekstis, on mudel kergelt killustatud. Mida suurem meeskond, seda suurem on probleem, kuid nii vähesed kui kolm või neli inimest võivad tekkida tõsiseid probleeme. Kuid süsteemi lagunemine üha väiksemates kontekstides kaotab lõpuks väärtusliku integratsiooni ja ühtsuse.

Seetõttu: inkorporeerige sageli kogu koodi ja muude rakenduste esemete ühendamise protsessi, automatiseeritud testidega, et kiiresti killustumist märgistada. Kasutage kõvasti kõvasti kõvasti keelt, et häkkida mudeli ühine vaade, kuna kontseptsioonid arenevad eri inimeste peades.

Kontekstide kaart

Individuaalne piiratud kontekst jätab mõned probleemid ülemaailmse vaate puudumisel. Muude mudelite kontekst võib endiselt olla ebamäärane ja voog.

Teised meeskonnaliikmed ei tunne väga hästi kontekstipiiranguid ja teevad teadlikult muudatusi, mis hävivad servi või raskendavad võrkudevahelisi ühendusi. Kui erinevates kontekstides tuleb teha ühendusi, kipuvad nad üksteisele verejooksu.

Seetõttu: määrake kindlaks iga mudeli mäng projektis ja määrake selle piiratud kontekst. See hõlmab mitte-objektorienteeritud alamsüsteemide kaudseid mudeleid. Nimetage iga piiratud konteksti ja tehke nimede osa üldlevinud keelest. Kirjeldage mudeleid puudutavaid kontaktpunkte, selgitades selgesõnalist tõlget mis tahes suhtlemiseks ja rõhutades mis tahes jagamist. Kaardige olemasolevat maastikku.

Puudused

Selleks, et aidata mudelit kui puhtat ja kasulikku keelekonstruktsiooni säilitada, peab meeskond tavaliselt kasutama domeeni mudelis suuresti isolatsiooni ja kapseldamist. Sellest tulenevalt võib domeenil põhineva disainiga seotud süsteem olla suhteliselt kõrge hinnaga. Ehkki domeenipõhine disain pakub mitmeid tehnilisi eeliseid, nagu hooldatavus, soovitab Microsoft seda kohaldada ainult keerukatele valdkondadele, kus mudel ja keeleprotsessid annavad selget kasu keerulise teabe edastamisel ning ühise arusaama väljatöötamisel domeen.

Viited

Artikkel on osaline tõlge siit: Domain-driven design

⇐ Tagasi meetodite juurde


Lauri Nugiseks TA15 15. november 2017, kell 12:51 (EET)