Als software engineer hoor je regelmatig dingen als TDD, DDD en SOA, vaak ook wel de TLA's (Three-Letter Abbreviations) genoemd. In context kun je die vaak wel plaatsen. Voor wie er niet bekend mee is, we hebben het hier over Test Driven Development, Domain Driven Development en Service Oriented Architecture.
Bij softwareontwikkeling is het vaak verstandig om tests te schrijven. Dat zijn kleine stukjes code die een heel specifiek stukje van het programma testen op correct functioneren. Dit is handig wanneer je met veel mensen aan dezelfde sourcecode werkt, omdat een wijziging op de ene plek vaak de functionaliteit van een totaal ander stuk code beïnvloed. Daarnaast is het lastig om te zien wat een bepaalde wijziging in de code precies voor gevolgen heeft, dus worden tests ingezet om voor alle gespecificeerde use cases (manieren waarop de applicatie kan worden gebruikt) te testen of alles nog in orde is.
Een manier om minder van dit soort effecten te hoeven testen, is ervoor te zorgen dat er minder lange-afstandseffecten zijn. Dit kan door het scheiden van de code in stricte brokken, die elkaar op geen enkele manier mogen beïnvloeden, behalve door communicatie via strict omschreven protocollen, meestal via internet. Door dit te doen, hoeven alleen de communicatievlakken (API's) nog maar te worden getest op correct functioneren.
Als dit gebeurt door binnen de software dergelijke brokken te maken, dan heet dat vaak OOP, ofwel Object Oriented Programming en de tests van deze brokken Unit Tests. Als deze brokken over verschillende programma's worden uitgespreid, die vaak ook nog op totaal verschillende servers draaien, dan wordt dat vaak SOA, ofwel Service Oriented Architecture genoemd, en de tests Functional Tests. Iedere service krijgt een bepaalde verantwoordelijkheid toegewezen en de ontwikkelaars van de service zijn verantwoordelijk voor het correct functioneren van de service.
Naast de stricte scheiding van verantwoordelijkheden heeft SOA ook nog wat andere voordelen: iedere service kan zelf bepalen welke technieken het meest geschikt zijn voor die service of de programmeurs die hem onderhouden en iedere service kan zich focussen op het zo effectief mogelijk leveren van die service. Daarnaast zijn de services door meerdere clients te gebruiken.
Dit is natuurlijk vergelijkbaar met de "Service Oriented Architecture" die veel bedrijven impliciet al implementeren. De marketingafdeling specialiseert zich in X, de ontwikkelafdeling in Y en de klantenservice op Z. Verzoeken van de klantenservice worden in veel gevallen volgens een bepaalde procedure gecommuniceerd naar marketing.
Daarom sluit Domain Driven Development ook voor goed aan op SOA. In DDD probeert de ontwikkelaar de structuren, processen, functies en terminologie die binnen een bedrijf aanwezig zijn 1-op-1 over te nemen in de software. Dit zorgt voor meer duidelijkheid bij de communicatie tussen de ontwikkelaar en de gebruikers en geeft een natuurlijke structuur aan de codebase.
Voor veel developers is DDD de vanzelfsprekende aanpak die ze intuïtief volgen. Dit maakt dat getrainde developers vaak een goede analyse kunnen maken van bedrijfsstructuren en -processen en snel de onlogische indelingen of bottlenecks kunnen spotten.
Dus, wanneer u de volgende keer met een ontwikkelaar spreekt over het bouwen van een bedrijfsapplicatie, bedenk dan dat het ontwerpen van de applicatiestructuur misschien ook wel een goede gelegenheid biedt om de bedrijfsstructuur mee onder de loep te nemen.
Geen opmerkingen:
Een reactie posten