betydningen af allestedsnærværende sprog i Domænedrevet Design

de fleste kommercielle programmer er skabt med et sæt komplekse forretningsmæssige krav til at løse specifikke forretningsproblemer eller behov. Det er imidlertid også upraktisk at forvente, at alle programudviklere/arkitekter skal være eksperter på forretningsdomæner og forvente, at de kender hele forretningsfunktioner. På den anden side, hvordan skaber vi programmer, der giver værdi, og har forbrugere, der har brug for automatisering, der vil bruge programmerne? Et program kan ikke kun være et udstillingsgenstand for teknisk ekspertise, men i de fleste tilfælde også reel og Anvendelig af automatiseret forretningsekspertise. Det domænedrevne design og modeller er svarene på disse spørgsmål.

denne korte artikel taler om et af nøgleprincipperne for Domænedrevet Design kaldet “allestedsnærværende sprog”, da DDD-koncepter, principper og mønstre bringer teknologi og forretningsekspertise sammen til alle sofistikerede programmer, der kan oprettes og styres.

tal allestedsnærværende

allestedsnærværende sprog er en model, der fungerer som et universelt sprog for at hjælpe kommunikationen mellem programmeludviklere og domæneeksperter.

samarbejde, læring og definition af en model bringer en masse indledende kommunikationsbarrierer mellem programmelspecialister og domæneeksperter. Så udviklende domænemodel med at praktisere den samme type kommunikation (diskussioner, skrifter og i diagrammer) inden for en sammenhæng er afgørende for vellykkede implementeringer, og den slags samtale kaldes allestedsnærværende sprog. Det er struktureret omkring domænemodellen og bruges i vid udstrækning af alle teammedlemmer inden for en afgrænset kontekst. Det skal være mediet eller tilstanden at forbinde alle teamets aktiviteter inden for udvikling af programmer.

designteamet kan etablere dyb forståelse og forbinde domænejargoner og programenheder med allestedsnærværende sprog for fortsat at opdage og udvikle deres domænemodeller.

allestedsnærværende sprog

tilsvarende pseudokode

vi administrerer vacciner

Administrationvacciner {}

ikke et kernedomæne-har brug for nogle mere specifikke detaljer

vi administrerer flu Shots til patienter

patientNeedAFluShot()

bedre, kan være mangler nogle domænekoncepter

sygeplejersken administrerer flu vacciner til en patient i standarddoser

Sygeplejerske – > Administrer vaccine (patient, Vaccine.getStandardDose())

meget bedre, og kan være godt at starte med.

som vi observerer i ovenstående tabel, er der forskellige måder, hvorpå brugerhistorierne (krav) kan gives; den sidste række giver dog mening, da den har mere klarhed om, hvad og hvordan faktorer.

forhåbentlig hjælper denne artikel læserne med at få et glimt af, hvordan DDD-principper går ind for og hjælper med større samarbejde mellem emneeksperter, forretningsanalytikere, ikke-teknologiske interessenter med det tekniske/udviklingssamfund til at producere komplekse domænedrevne systemer.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.