Odpowiedź.

SRP — pierwszy z zasad SOLID, oznacza, że każda encja (moduł, usługa, klasa) powinna mieć tylko jeden powód do zmiany. Na poziomie architektury osiąga się to, dzieląc system na usługi/moduły według obszarów odpowiedzialności. Na przykład, jedna usługa rejestruje użytkowników, druga zarządza płatnościami, trzecia — wysyła powiadomienia.

Przykład w Node.js:

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

// paymentService.js
module.exports = {
  processPayment(order) { /* przetwarzanie płatności */ }
}

// notificationService.js
module.exports = {
  sendEmail(user, content) { /* wysyłanie maili */ }
}

Kluczowe cechy:

• Każda usługa/moduł odpowiada tylko za jeden proces biznesowy
• Zmiany w jednym obszarze nie wpływają na inne części systemu
• Łatwiej utrzymywać i skalować zespoły deweloperskie

Pytania z pułapką.

Czy SRP oznacza, że usługa nie może wchodzić w interakcje z innymi usługami?

Nie. Usługi mogą współpracować poprzez ściśle określone API, zachowując swoją odpowiedzialność za operacje biznesowe wewnątrz.

Czy można zrealizować SRP bez podziału na oddzielne pliki lub projekty?

Technicznie tak, ale dla skalowalności i czytelności kodu zaleca się podział na jednostki fizyczne: oddzielne pliki, pakiety, usługi.

Czy SRP dotyczy tylko kodu, czy całej architektury?

SRP jest aktualny na wszystkich poziomach: od projektowania usług/modułów po pisanie konkretnych klas i funkcji.