Dus ik kreeg deze vraag van een van de ontwikkelaars in mijn team: wat is domeingestuurd ontwerp? Ik zou natuurlijk kunnen verwijzen naar het boek van Evans, maar is dat eigenlijk een antwoord?
Hoe zou je DDD in een paar zinnen uitleggen aan junior software-engineers in je team?
Antwoord 1, autoriteit 100%
Ik zou zeggen dat deze praktijk bevordert dat je je inspanningen concentreert op de ‘probleemruimte’ in plaats van de ‘oplossingsruimte’. Aansturen van een emergente oplossing (het ontwerp) door het domein te bestuderen en echt te leren kennen en begrijpen. Een van de praktijken (overgenomen uit XP) zou het schrijven van verhalen zijn die zich voordoen in het probleemdomein. Hieruit kunt u uw gebruiksscenario’s en objecten voor uw ontwerp identificeren. Ze komen tevoorschijn en vertellen je wat er in de oplossing moet zitten en hoe ze met elkaar moeten omgaan.
Antwoord 2, autoriteit 50%
InfoQ heeft een gratis eBook:
Het is goed leesbaar met veel voorbeelden.
Antwoord 3, autoriteit 20%
Terwijl u het “domein” ontdekt, vormt u een gemeenschappelijke taal, die zowel de ontwikkelaars als alle andere belanghebbenden in het project begrijpen.
Het domeinmodel en zijn “lingo” is goed waarneembaar in de broncode voor het eindproduct. Dat is tenminste mijn ervaring
Antwoord 4, autoriteit 9%
Een belangrijk onderdeel van DDD is de zogenaamde alomtegenwoordige taal; d.w.z. dezelfde taal spreken als de bedrijfsexperts. En maak uw code / architectuur zo dat deze deze taal weerspiegelt om impedantieproblemen te voorkomen.
Antwoord 5, autoriteit 9%
Proberen te begrijpen waar de software die u schrijft over gaat en dat begrip weer te geven in het model.
Antwoord 6, autoriteit 4%
Domain Driven Design gaat over het beheren van de complexiteit van een applicatie in het domeinmodel waar deze het gemakkelijkst kan worden gedestilleerd.
Het is erg moeilijk om het in een paar zinnen te beschrijven, maar ik zou het InfoQboek aanraden als een goede introductie. Ik heb ook gehoord van veel mensen die een boekenclub organiseren met het DDD-boek van Evans, wat veel heeft geholpen om het te begrijpen.
Antwoord 7, autoriteit 4%
Voor mij is het volgende niveau van OOD/OOP waar de inkapseling draait om de probleemruimte, zoals beschreven en begrepen door gebruikers, en niet zozeer om de technische implementatie.