SRP is de eerste van de SOLID-principes en houdt in dat elke entiteit (module, service, klasse) slechts één reden tot wijziging moet hebben. Op architectonisch niveau wordt dit bereikt door het systeem op te splitsen in services/modules op basis van verantwoordelijkheidsgebieden. Bijvoorbeeld, een afzonderlijke service registreert gebruikers, de tweede beheert betalingen, de derde verstuurt meldingen.
Voorbeeld in Node.js:
// userService.js module.exports = { registerUser(data) { /* registratie */ } } // paymentService.js module.exports = { processPayment(order) { /* betalingsverwerking */ } } // notificationService.js module.exports = { sendEmail(user, content) { /* e-mails versturen */ } }
Belangrijke kenmerken:
Betekent SRP dat een service niet met andere services kan communiceren?
Nee. Services kunnen communiceren via duidelijk gedefinieerde API's, terwijl ze hun eigen verantwoordelijkheid voor bedrijfsoperaties intern behouden.
Kan SRP worden geïmplementeerd zonder onderverdeling in aparte bestanden of projecten?
Technisch gezien is het mogelijk, maar voor schaalbaarheid en leesbaarheid van de code wordt onderverdeling in fysieke eenheden aanbevolen: aparte bestanden, pakketten, services.
SRP alleen voor code of voor architectuur in het algemeen?
SRP is relevant op alle niveaus: van het ontwerpen van services/modules tot het schrijven van specifieke klassen en functies.