Antwort.

SRP ist das erste der SOLID-Prinzipien und besagt, dass jede Entität (Modul, Dienst, Klasse) nur einen Grund zur Änderung haben sollte. Auf der architektonischen Ebene wird dies erreicht, indem das System in Dienste/Module nach Verantwortungsbereichen aufgeteilt wird. Beispielsweise registriert ein separater Dienst die Benutzer, ein zweiter verwaltet Zahlungen, und ein dritter sendet Benachrichtigungen.

Beispiel in Node.js:

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

// paymentService.js
module.exports = {
  processPayment(order) { /* Zahlungsabwicklung */ }
}

// notificationService.js
module.exports = {
  sendEmail(user, content) { /* E-Mails versenden */ }
}

Wesentliche Merkmale:

• Jeder Dienst/Modul ist nur für einen Geschäftsprozess verantwortlich.
• Änderungen in einem Bereich beeinflussen nicht andere Teile des Systems.
• Es ist einfacher, Entwicklungsteams zu warten und zu skalieren.

Fangfragen.

Bedeutet SRP, dass ein Dienst nicht mit anderen Diensten interagieren kann?

Nein. Dienste können über klar definierte APIs interagieren und behalten dabei ihre eigene Verantwortung für Geschäftsoperationen.

Kann SRP ohne Trennung in separate Dateien oder Projekte umgesetzt werden?

Technisch möglich, aber für Skalierbarkeit und Code-Lesbarkeit wird eine Trennung in physische Einheiten empfohlen: separate Dateien, Pakete, Dienste.

Gilt SRP nur für den Code oder für die Architektur insgesamt?

SRP ist auf allen Ebenen relevant: von der Gestaltung von Diensten/Modulen bis hin zum Schreiben spezifischer Klassen und Funktionen.