Wat ik begrijp van domain-driven design
On november 15, 2021 by adminDD 101
Hoe groter het project, des te moeilijker het is om het te onderhouden. Een manier om daarbij te helpen is het opdelen van de app in kleinere gebieden volgens hun bedrijfsregels, domeinen genoemd.
Basically, a domain is an area of knowledge, either public, like the rules of chess, or private, like the business rules of a nonprofit organization .
Een complex domein zal waarschijnlijk kennis uit andere domeinen gebruiken. Zo zal een NPO die online schaakles geeft, kennis hebben van schaken, van lesgeven via online platforms, en, ook al word je als student niet afgerekend, van de financiën.
Elk subdomein van je domein staat in DDD bekend als begrensde contexten, elk heeft zijn eigen model van de wereld dat is opgebouwd uit gespecialiseerde eenheden code, bouwstenen genoemd. Hier zal ik me richten op entiteiten en waarde-objecten, beide kunnen worden aangeduid als objecten.
Entiteiten zijn objecten die bedoeld zijn om uniek te zijn binnen het domein. Dit wordt bereikt door een of meer eigenschappen te gebruiken om een bepaalde entiteit te identificeren. Zo zullen twee gebruikers met dezelfde naam in een systeem altijd verschillende emails hebben, omdat emails niet kunnen worden herhaald – meestal worden entiteiten onderscheiden door een id, en soms door een combinatie van proprieties.
Value-objecten daarentegen hebben geen identiteit, zodat alleen hun eigenschappen kunnen worden gebruikt om twee instanties te onderscheiden. Neem bijvoorbeeld twee pionnen (de schaakstukken), ze zien er hetzelfde uit als ze uit dezelfde set komen en dezelfde kleur hebben, dus het maakt niet uit als je ze omwisselt. In DDD zijn waarde-objecten onveranderlijk, zodat het gemakkelijker is om met ze te redeneren.
Gegevensintegriteit
Een begrensde context stelt niet al zijn objecten bloot om zijn gegevensintegriteit te garanderen. In plaats daarvan stelt het sommige aggregate wortels bloot als een soort openbare interface voor zichzelf.
Een aggregate is niets meer dan een entiteit die is samengesteld uit andere objecten. Om precies te zijn is een aggregaat een cluster van geassocieerde objecten die we als een eenheid behandelen wanneer we gegevens wijzigen.
In praktische termen zullen aggregaten de vorm aannemen van de gegevensstructuur die bekend staat als een boom. En om die reden hebben alle aggregates een root.
Het enige lid van een aggregate waarnaar andere objecten kunnen verwijzen is de root, en dit is dus wat we blootleggen. Dit wordt zo gedaan omdat het voorkomt dat andere objecten gegevens kunnen tweaken op een manier die het aggregaat niet kan controleren.
Het is belangrijk om duidelijk te maken dat een begrensde context veel aggregaten kan gebruiken, zelfs als hun root niet direct aan de buitenwereld wordt blootgesteld.
Omgaan met meerdere begrensde contexten
Maar de dingen kunnen ingewikkelder worden, toch? Elke begrensde context krijgt een iets ander model van dezelfde objecten, met andere eigenschappen en gedragingen. Zo kan een gebruiker in een spelcontext een eigenschap hebben om zijn score te hanteren die in een financiële context irrelevant is en dus niet bestaat.
En dat is nog niet alles. Het is ook mogelijk dat een domeinconcept, voorgesteld als een entiteit in een begrensde context, wordt voorgesteld als een object-waarde in een andere, of gewoon volledig wordt weggelaten.
Terwijl de onderwijscontext bijvoorbeeld eist dat leraren als entiteiten worden gerepresenteerd, zodat zij aan de hand van hun id’s aan leerlingen kunnen worden toegewezen, ziet de financiële context “leraar” liever als een waarde voor de positie-eigenschap van de werknemersentiteit.
Enkele andere DDD-bouwstenen zijn services, repositories, factories en events. Ik zal proberen ze kort te beschrijven.
Services zijn mogelijkheden van een domein die niet van nature passen bij entiteiten of object-waarden. Let op dat het domeinservices zijn, geen applicatie- of infrastructuurservices.
Repositories zijn bruggen naar opslageenheden – hallo CRUD!.
Factories zijn methoden om domeinobjecten te maken, zodat ze nooit ongeldige waarden hebben. Dit deel is wat me aan het denken heeft gezet over product-gedreven tests.
Events zijn objecten die iets vertegenwoordigen dat in het domein is gebeurd – de experts geven om hen. Geweldige mogelijkheden om een event-driven applicatie te maken.
Hoewel ik me niet kan herinneren dat Evans dit heeft gezegd, zijn bounded contexts een mooie gelegenheid om je code op te splitsen in microservices, waarbij elke service een context op zich is. De eerste stap zou een “virtuele” opsplitsing kunnen zijn, waarbij elke context in een andere module op dezelfde app wordt gezet, en als je dan ontdekt dat ze echt geïsoleerd zijn, verplaats je ze naar verschillende.
Een taal om ze allemaal te overheersen
Een van de eerste dingen die mensen leren bij het bestuderen van DDD is dat hun systeem moet worden beschreven door een alomtegenwoordige taal. Dat wil zeggen dat we code moeten schrijven met dezelfde werkwoorden (voor methoden of diensten) en zelfstandige naamwoorden (voor objecten) die de domeinexperts gebruiken als ze tegen ons praten.
Het op deze manier schrijven van code heeft het voordeel dat de communicatiekloof tussen ontwikkelaars en experts wordt gedicht als ze met elkaar praten, maar het is een oversimplificatie van het echte leven, dus ik gebruik het persoonlijk als een richtlijn, maar niet als een definitieve oplossing.
Ik heb het tot het laatst bewaard omdat, voor mij, het belangrijkste over DDD meestal niet wordt gelezen, omdat het in het “complexe” deel van het boek staat.
Nu heb ik vernomen dat de auteur zelf heeft gezegd dat de volgorde waarin hij dingen in het boek presenteert niet optimaal is, en wat ik hier heb beschreven ligt dichter bij wat ideaal zou zijn geweest 😍. Ik hoorde het op een podcast die hiernaar verwees
Geef een antwoord