De fem kendetegn ved en god domænemodel

Jeg prøvede at finde ud af en god definition af en domænemodel til dette blogindlæg. Alle mine anstrengelser førte til en noget klodset forklaring. Jeg var dog i stand til at finde en god definition af en domænemodel fra Wikipedia:

En domænemodel inden for problemløsning og softwareudvikling kan opfattes som en konceptuel model af et interessedomæne (ofte omtalt som et problemdomæne), der beskriver de forskellige enheder, deres egenskaber og relationer plus de begrænsninger, der styrer integriteten af modelelementerne, der omfatter det pågældende problemdomæne.

Lyder det vigtigt eller hvad? Med andre ord er en domænemodel en væsentlig del af enhver applikation, og den er en repræsentation af virkelige verdens koncepter. Men hvordan kan du skelne en god domænemodel fra en dårlig? Svaret på det spørgsmål er ikke indlysende, fordi forståelsen af ​​domænemodellen kræver, at du også forstår problemdomænet. Mit mål er at gøre denne opgave lidt lettere ved at beskrive dig de fem karakteristika ved en god domænemodel.

En domænemodel er sandsynligvis en god, hvis den

Modellerer problemdomænet korrekt . En god domænemodel er ikke nødvendigvis en nøjagtig kopi fra den virkelige verden, men den skal modellere problemdomænet med den nødvendige nøjagtighed. Det betyder, at den kun skal indeholde de oplysninger, som er relevante for at løse det givne problem. Unødvendig information skal udelukkes fra domænemodellen, selvom den ville eksistere i den virkelige verden. Det er dog ikke nok at indeholde de rigtige enheder. Sammenslutningerne af disse enheder skal også være korrekte. Problemet er, at før du kan bedømme en domænemodel ved at bruge disse kriterier, bør du have noget viden fra problemdomænet.

Taler det rigtige sprog . Fordi en domænemodel er en repræsentation af et problemdomæne, er det vigtigt, at dets elementer er blevet navngivet korrekt. Dette sikrer, at både bygherren og underleverandøren taler samme sprog. At tale samme sprog er vigtigt, fordi det minimerer muligheden for misforståelser, som reducerer kvaliteten, der leveres til kunden. Det er ret simpelt at verificere, om den analyserede domænemodel opfylder dette krav. Hvis elementerne i domænemodellen er blevet navngivet korrekt, burde din kunde kunne forstå det uden problemer.

Gør krav på ejerskab af sine oplysninger . En god domænemodel styrer ændringerne i dens information. Det betyder, at det bør give metoder til at manipulere indholdet og forbyde alle andre ændringer af oplysningerne under dets kontrol. At give kun et enkelt adgangspunkt til oplysningerne i en domænemodel har to store fordele:det reducerer duplikatkode og beskytter domænemodellens integritet. At følge denne retningslinje vil således føre til en renere og mindre fejltilbøjelig kode, hvilket burde være målet for enhver softwareingeniør.

Hvis du også har brug for information, som udelukkende er baseret på domænemodellen og ikke har andre afhængigheder, bør du placere den metode, der giver disse oplysninger til domænemodellen. Denne tilgang følger princippet om adskillelse af bekymringer, og den vil forbedre kvaliteten af ​​din kode ved at tydeliggøre arkitekturen af ​​din software.

At følge disse retningslinjer vil også hjælpe dig med at undgå et antimønster kaldet Anæmisk domænemodel.

Giver indbygget support til logning . Fordi det ofte er nyttigt at skrive indholdet af et objekt til en logmeddelelse, bør en domænemodel give en enkel måde at hente indholdet af en enhed som en streng. Dette sikrer, at du ikke behøver at konstruere logmeddelelser manuelt. Alt du skal gøre er at tilføje det pågældende objekt til en logmeddelelse, og så er du klar.

Er dækket af enhedstests . Denne egenskab ved en god domænemodel er lidt indlysende (i hvert fald for fagfolk), men jeg har lært, at antagelser kan være farlige. Det er grunden til, at jeg ville skrive et par ord ned om enhedstest af en domænemodel. Selvom jeg ved, at præcise retningslinjer kan være farlige, tror jeg, at det i dette tilfælde er muligt at præsentere en nøjagtig retningslinje for enhedstest af enhver domænemodel. Du skal simpelthen teste hver metode, som ikke er en getter- eller setter-metode.

Jeg har nu beskrevet dig de fem karakteristika ved en god domænemodel. Jeg håber, at dette blogindlæg vil hjælpe dig med at skelne en god domænemodel fra en dårlig, og måske give dig nogle tips til, hvordan du kan transformere en dårlig domænemodel til en god.

PS. Hvis du har designet en domænemodel fra bunden, vil du måske finde denne præsentation om domænemodellering nyttig. Jeg kan også anbefale en bog kaldet Domain-Driven Design af Eric Evans. Den er fuld af nyttig information om domænemodellering, og efter min mening er den et must at læse for enhver softwareudvikler.