betydelsen av allestädes närvarande språk i Domändriven Design

de flesta kommersiella programvaror skapas med en uppsättning komplexa affärskrav för att lösa specifika affärsproblem eller behov. Att förvänta sig att alla mjukvaruutvecklare / arkitekter är experter på affärsdomäner och förväntar sig att de känner till hela affärsfunktioner är också opraktiskt. Å andra sidan, Hur skapar vi programvara som ger värde och har konsumenter som behöver automatisering som kommer att använda programvaran? En programvara kan inte bara vara ett showpiece av teknisk excellens, men i de flesta fall också verklig och användbar för automatiserad affärskompetens. Den domändrivna designen och modellerna är svaren på dessa frågor.

den här korta artikeln talar om en av de viktigaste principerna för Domändriven Design som kallas ”allestädes närvarande språk”, eftersom DDD-koncept, principer och mönster förenar teknik och affärskompetens till alla sofistikerade program som kan skapas och hanteras.

prata allestädes närvarande

ubiquitously language är en modell som fungerar som ett universellt språk för att hjälpa kommunikation mellan programutvecklare och domänexperter.

att samarbeta, lära sig och definiera en modell ger många initiala kommunikationsbarriärer mellan mjukvaruspecialister och domänexperter. Så utvecklande domänmodell med att öva samma typ av kommunikation (diskussioner, skrifter och i diagram) inom ett sammanhang är avgörande för framgångsrika implementeringar, och den typen av konversation kallas allestädes närvarande språk. Den är strukturerad kring domänmodellen och används i stor utsträckning av alla teammedlemmar inom ett avgränsat sammanhang. Det borde vara mediet eller läget för att ansluta alla aktiviteter i laget inom utveckling av programvara.

designteamet kan skapa djup förståelse och ansluta domänjargon och mjukvaruenheter med allestädes närvarande språk för att fortsätta upptäcka och utveckla sina domänmodeller.

allestädes närvarande språk

motsvarande pseudokod

vi administrerar vacciner

Administreravacciner {}

inte en kärndomän-behöver lite mer specifika detaljer

vi administrerar influensaskott till patienter

patientNeedAFluShot()

bättre, kan vara saknar några domänkoncept

sjuksköterskan administrerar influensavacciner till en patient I standarddoser

Sjuksköterska- >administrera vaccin (patient, vaccin.getStandardDose())

mycket bättre, och kan vara bra att börja med.

som vi observerar i tabellen ovan finns det olika sätt som användarhistorierna (kraven) kan ges; den sista raden är dock meningsfull eftersom den har mer tydlighet om vad och hur faktorer.

förhoppningsvis hjälper den här artikeln läsarna att få en glimt av hur DDD-principer förespråkar och hjälper till med större samarbete mellan ämnesexperter, affärsanalytiker, icke-tekniska intressenter med det tekniska/utvecklingsgemenskapen för att producera komplexa domändrivna system.

Lämna ett svar

Din e-postadress kommer inte publiceras.