Réponse.

Le SRP est le premier des principes SOLID, indiquant qu'une entité (module, service, classe) ne doit avoir qu'une seule raison de changer. Au niveau architectural, cela se réalise en fragmentant le système en services/modules selon les domaines de responsabilité. Par exemple, un service distinct enregistre les utilisateurs, un autre gère les paiements, un troisième envoie des notifications.

Exemple en Node.js :

// userService.js
module.exports = {
  registerUser(data) { /* enregistrement */ }
}

// paymentService.js
module.exports = {
  processPayment(order) { /* traitement du paiement */ }
}

// notificationService.js
module.exports = {
  sendEmail(user, content) { /* envoi d'e-mails */ }
}

Caractéristiques clés :

• Chaque service/module est responsable d'un seul processus métier
• Les changements dans un domaine n'affectent pas d'autres parties du système
• Il est plus facile de maintenir et d'évoluer les équipes de développement

Questions pièges.

Le SRP signifie-t-il qu'un service ne peut pas interagir avec d'autres services ?

Non. Les services peuvent interagir via des API clairement définies, tout en préservant leur propre responsabilité pour les opérations commerciales en interne.

Peut-on mettre en œuvre le SRP sans division en fichiers ou projets séparés ?

Techniquement possible, mais pour la scalabilité et la lisibilité du code, il est recommandé de diviser par unités physiques : fichiers séparés, paquets, services.

Le SRP concerne-t-il uniquement le code ou l'architecture dans son ensemble ?

Le SRP est pertinent à tous les niveaux : de la conception de services/modules jusqu'à l'écriture de classes et fonctions spécifiques.