单一职责原则（SRP）应用困惑：用户注册场景下的疑问

Great question—this is such a common sticking point when learning the Single Responsibility Principle (SRP)! Let’s unpack why your refactor actually fixes the SRP violation, and clarify what SRP really means.

First, let’s recap the core of SRP: a class should have only one reason to change. It’s not about "a class can only do one thing"—it’s about isolating different sources of change so that a tweak to one part of your system doesn’t force changes to unrelated parts.

Why the Original Code Violates SRP #

In your initial UserService:

• It handles user CRUD operations (changes here would come from things like updating user database schema, adding new user fields, or modifying registration validation rules).
• It also contains the full logic for sending verification emails (changes here would come from updating email templates, switching email providers, or modifying OTP generation logic).

This means UserService has two distinct reasons to change—any tweak to email logic requires touching the same class that handles user data, which is a classic SRP violation.

Why Your Refactor Fixes the SRP Violation #

Your refactored code moves all email-specific logic into EmailService, and UserService only delegates to it via sendVerificationEmail(). Let’s break down the reasons to change now:

• UserService only changes when user domain logic needs updating (e.g., adding a required "phone number" field to registration, changing how users are persisted to the database). The email delegation code won’t change unless the trigger for sending the email changes (like "only send emails if the user opted in")—which is still part of user registration logic, not email logic.
• EmailService only changes when email-related requirements change (e.g., updating the OTP length, changing the email subject, switching from SMTP to a transactional email API). None of these changes will affect UserService at all.

The key here is that UserService no longer owns the email implementation—it just knows that an email needs to be sent after registration, and delegates that responsibility to the dedicated EmailService. This separates the two distinct sources of change, which is exactly what SRP is meant to achieve.

A Further Optimization (Optional) #

If you want to take this even further, you could decouple UserService from knowing about EmailService entirely using an event-driven approach:

1. When UserService successfully registers a user, it publishes a UserRegisteredEvent with the user’s details.
2. An EmailNotificationListener listens for this event and calls EmailService to send the verification email.

This way, UserService doesn’t even know that an email exists—its only job is to handle user registration. But even without this step, your current refactor is fully compliant with SRP.

内容的提问来源于stack exchange，提问作者Manikandan Kbk DIP