Tof, zo'n Domain Model

Door E-sites, E-sites
8 mei 2014 - 1523 x bekeken - Categorieën: Kennis

Voor eenvoudige problemen zijn er eenvoudige oplossingen. Maar als het probleem complexer wordt, hoeft dat nog niet te gelden voor de oplossing.

De Jongsters

Onlangs werd het nieuwe online platform De Jongsters gelanceerd. Een initiatief van voetbalbroers Siem en Luuk de Jong. Op dit platform worden jongeren uitgedaagd het beste uit zichzelf te halen. Zowel op het voetbalveld als thuis en op school. Via deze website gaan jongeren challenges aan, waarmee ze punten kunnen scoren. Deze opdrachten kunnen ze individueel uitvoeren of met een team waarbij ze zich aan kunnen sluiten.

Complexe regels, checks en interacties

Toen we begonnen aan het Jongsters project werd al snel duidelijk dat er veel regels waren waaraan voldaan zou moeten worden. Denk hierbij aan complexe regels als ‘je mag iemand uitnodigen voor je team indien jij de beheerder bent, diegene niet de beheerder van een ander team is, diegene niet eerder uitgenodigd is voor jouw team en jouw team niet vol is’. Vaak zie je dat dergelijke regels, of 'business rules', worden afgedwongen in de 'controller'; de code die de input van de gebruiker afvangt en aan de hand daarvan het systeem opdracht geeft bepaalde acties uit te voeren.

Voor eenvoudige gevallen is dit prima; de controle die gedaan moet worden is erg eenvoudig en kan in een kleine hoeveelheid code omschreven worden. Maar bovengenoemde business rule beslaat toch al snel een regel of twintig; simpelweg veel te veel om in je controller te proppen. Daarnaast is een dergelijke check bij dit soort projecten op meerdere plaatsen nodig. We hebben ook te maken met complexe interacties tussen verschillende “entiteiten”. Een voorbeeld van een entiteit is bijvoorbeeld een Jongster, een Team, of een Uitdaging. Een interactie tussen Jongster en Team is bijvoorbeeld ‘Vragen of je lid mag worden. Een andere interactie, tussen twee Jongsters en een Team is ‘Uitnodigen’. Ook deze interacties zijn te complex om in de controller te plaatsen. Daarnaast zou dit ook het Single Responsibility Principle schenden: een stuk code mag maar één taak hebben en voor een controller is dit “vertaal de input van de gebruiker naar acties voor het systeem”.

Een Domain model biedt uitkomst

Binnen dit project hebben we ervoor gekozen om het valideren van business rules en implementeren van interacties onder te brengen in een 'Domain model'. Dit is een modellering van je “probleemdomein”, ofwel het gebied waarin je, binnen de applicatie, geïnteresseerd bent, onafhankelijk van al het andere. De eerder genoemde controllers bijvoorbeeld zijn geen onderdeel van het domain model; controllers zijn bezig met invoer van de gebruiker dat geen onderdeel is van dit “interessante gebied”. Hetzelfde geldt bijvoorbeeld ook voor de database interactie. Hoewel beide noodzakelijk zijn, behoren ze niet tot het probleemdomein: het zijn randzaken die bij de infrastructuur van de applicatie horen.

Wat juist wel binnen het probleemdomein behoort is de interactie "Jongster doet mee aan een Uitdaging", welke resulteert in een Inzending. Deze interactie heeft gevolgen als "het aantal Inzendingen voor de Uitdaging is hoger geworden" en "het aantal punten van Jongster is verhoogd met het aantal punten dat hoort bij de Uitdaging, mits dit de eerste Inzending voor deze Uitdaging van deze Jongster is". Deze interactie is in het model hieronder gemodeleerd als de "doet mee aan" link tussen Jongster en Uitdaging.

Een andere interessante interactie is die waarbij één Jongster een andere Jongster uitnodigd voor zijn of haar Team. Deze interactie heeft, zoals eerder gezegd, een aantal regels. Een voorbeeld hiervan is dat de uitnodigende Jongster de aanvoerder van het Team moet zijn. Daarnaast zijn er aan aantal gevolgen. Één daarvan is dat de uitgenodigde Jongster een notificatie krijgt. Het hoe van die notificatie is daarbij niet zozeer van belang (in ons geval een e-mail). Een ander gevolg is dat de Jongster vanaf dat moment op de Team-pagina op "Lid worden" kan klikken.

Het op deze manier focussen op het probleemdomein doen we nu nog niet vaak, terwijl het duidelijke voordelen met zich meebrengt. Het heeft er bijvoorbeeld voor gezorgd dat de code binnen onze controllers veel beknopter is gebleven en dat functionaliteit op een logischere manier gebundeld is. Wel vereist het, vooral in het begin, wat discipline: omdat een vrij eenvoudige interactie moet worden opgedeeld in meerdere lagen, voelt het soms alsof je te veel onnodig werk doet. Pas later, wanneer je zaken uit gaat breiden, merk je pas echt wat de voordelen zijn.

Al met al zijn we als team erg tevreden over het resultaat, zowel qua functionaliteit als qua technische opzet. We hebben er dan ook veel vertrouwen in dat nu het uitbreiden van het platform een stuk eenvoudiger zal zijn!

Lees hier meer over De Jongsters.

De wereld door een slimme bril: Google Glass

Door E-sites

“OK Glass, take a picture.” Eén keer knipperen en er wordt een foto gemaakt van het restaurant waar ik voor sta… - Lees meer

Lees verder