Betydningen Av Allestedsnærværende Språk I Domenedrevet Design

de fleste kommersielle programmer er opprettet med et sett av komplekse forretningskrav for å løse spesifikke forretningsproblemer eller behov. Men forventer alle programvareutviklere / arkitekter å være eksperter på forretningsdomener og forventer at de skal vite hele forretningsfunksjonene, er også upraktiske. På den annen side, hvordan lager vi programvare som gir verdi og har forbrukere som har behov for automatisering som vil bruke programvaren? Et program kan ikke bare være et utstillingsvindu for teknisk fortreffelighet, men i de fleste tilfeller også ekte og brukbar av automatisert forretningskvalitet. Domenedrevet design og modeller er svarene på disse spørsmålene.

denne korte artikkelen snakker om en av de viktigste prinsippene For Domene-Drevet Design kalt «Allestedsnærværende Språk» SOM DDD konsepter, prinsipper og mønstre bringe teknologi og business excellence sammen til alle avanserte programmer som kan opprettes og administreres.

Talk Allestedsnærværende

Allestedsnærværende språk er en modell som fungerer som et universelt språk for å hjelpe kommunikasjon mellom programvareutviklere og domeneeksperter.

Samarbeid, læring og definisjon av en modell gir mange innledende kommunikasjonsbarrierer mellom programvarespesialister og domeneeksperter. Så utviklende domenemodell med å praktisere samme type kommunikasjon (diskusjoner, skrifter og diagrammer) i en kontekst er avgjørende for vellykkede implementeringer, og den slags samtale kalles Allestedsnærværende Språk. Den er strukturert rundt domenemodellen og brukes mye av alle lagmedlemmene i en begrenset kontekst. Det bør være medium eller modus for å koble alle aktivitetene i teamet innen utvikling av programvare.

designteamet kan etablere dyp forståelse og koble domenesjargonger og programvareenheter Med Allestedsnærværende språk for å fortsette å oppdage og utvikle sine domenemodeller.

Allestedsnærværende Språk

Tilsvarende Pseudokode

Vi Administrerer Vaksiner

AdministerVaccines {}

Ikke et kjernedomene-trenger noen mer spesifikke detaljer

vi administrerer influensaskudd til pasienter

pasientneedaflushot()

Bedre, kan være mangler noen domenekonsepter

sykepleieren administrerer influensavaksiner til en pasient i standarddoser

Sykepleier – > administrer vaksine (pasient, Vaksine.getStandardDose())

Mye bedre, og kan være bra å begynne med.

Som vi observerer i tabellen ovenfor, er det ulike måter brukerhistoriene (krav) kan gis på; den siste raden er imidlertid fornuftig da den har mer klarhet om hva og hvordan faktorer.

Forhåpentligvis hjelper denne artikkelen leserne til å få et glimt av hvordan ddd-prinsippene fortaler og bidrar til større samarbeid mellom fageksperter, forretningsanalytikere, ikke-teknologiske interessenter med det tekniske/utviklingssamfunnet for å produsere komplekse domenedrevne systemer.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.