[User] Implement Change Password Use Case (MVP Scope)

[tlavu2004]

📌 Description

As part of the MVP scope, we will implement only the password change functionality for authenticated users.
Other profile update features (email, display name, avatar, etc.) are intentionally out of scope for now and will be handled in future iterations.

This task focuses on delivering a clean, secure, and well-scoped Change Password use case following Clean Architecture and CQRS principles.

---

🎯 Objective

• Allow an authenticated user to change their password.
• Enforce proper validation and security rules.
• Keep the implementation minimal and aligned with MVP goals.

---

🧱 Scope & Design Decisions

✅ Included in this task

• Change password using current password verification
• Hash and persist the new password
• Use a dedicated command/use case (no shared “update profile” abstraction)
• Follow Clean Architecture boundaries

❌ Explicitly out of scope

• Updating email
• Updating display name
• Avatar management
• Batch profile updates
• Audit logging (can be added later)

---

📂 Proposed Structure (Application Layer)

application/
 └── user/
     └── usecase/
         └── command/
             ├── ChangePasswordCommand.java
             └── ChangePasswordHandler.java

---

🧩 Responsibilities

ChangePasswordCommand

• Data carrier only (no business logic)

• Contains:

  • userId
  • currentPassword
  • newPassword

ChangePasswordHandler

• Load user from repository
• Verify current password
• Apply password change (hashing handled in domain or service)
• Persist updated user

---

🔐 Domain Considerations

• Password validation and hashing logic should reside in:

  • Domain service or
  • Value object (e.g., Password)

• The use case must not contain cryptographic logic.

---

✅ Acceptance Criteria

• User can change password only when current password is valid
• New password is securely hashed
• No side effects on other user data
• Clean separation between application and domain layers

---

🧭 Notes

• Future features such as UpdateEmail, UpdateProfile, or UpdateAvatar will be implemented as separate commands, not combined into a generic update use case.
• This keeps the system explicit, auditable, and easy to evolve.