Domain-driven design
Softwaremodellen vanuit het vakgebied ontwikkelen, samen met de mensen die de regels ervan kennen.
Wat is domain-driven design?
Domain-driven design, kortweg DDD, baseert softwaremodellering op een bedrijfsdomein. Domeindeskundigen en ontwikkelaars verduidelijken samen begrippen, regels en verbanden. Een gedeelde taal moet binnen een afgebakende bedrijfscontext dezelfde betekenis hebben. Verschillende contexten kunnen eigen modellen nodig hebben; die grens heet vaak een bounded context.
In een fictief bedrijf bedoelt verkoop met ‘order’ een verkochte dienst, terwijl het serviceteam een ingepland bezoek bedoelt. Betrokkenen beschrijven beide betekenissen en de overdracht in plaats van stilzwijgend één gegevensmodel aan te nemen. Dat kan duidelijkere softwaregrenzen opleveren. DDD verplicht echter niet tot microservices of een bepaald databasetype. Technische opsplitsing en beheer van modellen vormen een aanvullende architectuurkeuze.
Bronnen
Verwante begrippen
- SoftwarearchitectuurFundamentele keuzes over structuur, samenwerking en kwaliteitsdoelen van een softwaresysteem.
- Modulaire monolietEen gezamenlijk uitgerolde toepassing met expliciet afgebakende interne modules en interfaces.
- Cache stampedeEen cache stampede ontstaat wanneer gelijktijdige cachemissers dezelfde dure berekening of gegevensopvraag herhaaldelijk starten.
- BackpressureBackpressure stemt de instroom van gegevens af op de verwerkingscapaciteit van de ontvanger via signalen om te vertragen of te pauzeren.
- Race conditionEen fout resultaat hangt af van de tijdsvolgorde van overlappende toegang.
- GeheugenlekNiet meer nodig geheugen blijft tijdens gebruik onnodig vastgehouden.
Artikelen over dit onderwerp
Uw project met ASES
Beschrijf ons uw project. We nemen contact met u op met een eerste inschatting.