Respuesta.

SRP es el primero de los principios SOLID, lo que implica que cada entidad (módulo, servicio, clase) debe tener una sola razón para cambiar. A nivel arquitectónico, esto se logra dividiendo el sistema en servicios/módulos según las áreas de responsabilidad. Por ejemplo, un servicio separado registra usuarios, otro gestiona pagos, y otro envía notificaciones.

Ejemplo en Node.js:

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

// paymentService.js
module.exports = {
  processPayment(order) { /* procesamiento de pagos */ }
}

// notificationService.js
module.exports = {
  sendEmail(user, content) { /* envío de correos */ }
}

Características clave:

• Cada servicio/módulo es responsable solo de un proceso de negocio
• Los cambios en un área no afectan a otras partes del sistema
• Más fácil de mantener y escalar para los equipos de desarrollo

Preguntas capciosas.

¿Significa SRP que un servicio no puede interactuar con otros servicios?

No. Los servicios pueden interactuar a través de APIs claramente definidas, manteniendo su propia responsabilidad sobre las operaciones comerciales internamente.

¿Se puede implementar SRP sin dividir en archivos o proyectos separados?

Técnicamente es posible, pero para la escalabilidad y legibilidad del código se recomienda la división en unidades físicas: archivos separados, paquetes, servicios.

¿SRP solo para el código o para la arquitectura en general?

SRP es aplicable a todos los niveles: desde el diseño de servicios/módulos hasta la escritura de clases y funciones específicas.