Answer.

SRP is the first of the SOLID principles, which states that every entity (module, service, class) should have only one reason to change. At the architectural level, this is achieved by breaking the system down into services/modules by areas of responsibility. For example, a separate service registers users, another manages payments, and a third sends notifications.

Example in Node.js:

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

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

// notificationService.js
module.exports = {
  sendEmail(user, content) { /* sending emails */ }
}

Key Features:

• Each service/module is responsible only for one business process
• Changes in one area do not affect other parts of the system
• Easier to maintain and scale development teams

Trick Questions.

Does SRP mean that a service cannot interact with other services?

No. Services can interact through well-defined APIs, while maintaining their own responsibility for business operations inside.

Can SRP be implemented without separating into individual files or projects?

Technically possible, but for scalability and code readability, separation into physical units such as separate files, packages, or services is recommended.

Is SRP only for code or for architecture as a whole?

SRP is relevant at all levels: from designing services/modules to writing specific classes and functions.