[volume-1] 회원가입, 내 정보 조회, 비밀번호 변경 기능 구현 및 아키텍처 리팩토링#22
Merged
madirony merged 30 commits intoLoopers-dev-lab:madironyfrom Feb 10, 2026
Merged
[volume-1] 회원가입, 내 정보 조회, 비밀번호 변경 기능 구현 및 아키텍처 리팩토링#22madirony merged 30 commits intoLoopers-dev-lab:madironyfrom
madirony merged 30 commits intoLoopers-dev-lab:madironyfrom
Conversation
- AuthenticationFilter 추가 (X-Loopers-LoginId, X-Loopers-LoginPw 헤더 인증) - GET /api/v1/members/me 엔드포인트 구현 - 이름 마스킹 적용 (마지막 글자를 *로 변경) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Password.change() 메서드 추가 (현재 비밀번호 확인, 새 비밀번호 검증, 동일 비밀번호 방지) - Member.updatePassword()를 Password.change() 위임으로 단순화 - 사용되지 않는 Member.getMaskedName() 제거 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- PUT /api/v1/members/me/password 엔드포인트 추가 - MemberService.changePassword() 메서드 추가 - 현재 비밀번호 확인, 동일 비밀번호 방지, 정책 검증 포함 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
[What] - Application Layer에 MemberFacade를 추가하여 트랜잭션 관리 책임 위임 - Domain Layer의 MemberService에서 Spring 의존성(@service, @transactional) 제거 - DomainConfig를 생성하여 MemberService를 수동 빈으로 등록 [Why] - 도메인 로직의 순수성(Purity) 확보 및 프레임워크 의존성 제거 - 비즈니스 흐름 제어(Application)와 핵심 로직(Domain)의 역할 분리
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
🤖 Fix all issues with AI agents
In
`@apps/commerce-api/src/main/java/com/loopers/domain/member/MemberService.java`:
- Around line 18-37: The signup method in MemberService currently checks
existsByMemberIdValue then calls memberRepository.save which can still race;
wrap the memberRepository.save(...) call inside a try-catch that catches the DB
unique-key/DataIntegrityViolation/DuplicateKey exception types thrown by your
persistence layer and rethrow a CoreException(ErrorType.CONFLICT, "이미 존재하는 회원
ID입니다.") so duplicate-key errors are normalized through ApiControllerAdvice;
keep or remove the pre-check as an optimistic fast-fail but do not rely on it
for correctness. Also add an integration test that issues concurrent signup
requests with the same memberId and asserts one succeeds while the other
receives a CONFLICT CoreException-mapped response. Use the signup(SignupCommand)
method name and memberRepository.save symbol to locate where to change.
In `@apps/commerce-api/src/main/java/com/loopers/domain/member/vo/BirthDate.java`:
- Around line 15-45: The BirthDate value object is missing value-based equality;
implement equals(Object) and hashCode() in the BirthDate class so equality is
based solely on the private String value (null-safe), mirroring other VOs like
Name; locate the BirthDate class and add overrides for equals and hashCode that
compare the value field and compute hash from it (ensure consistent behavior
with toPlainString and no other fields are considered).
- Around line 25-28: The BirthDate constructor currently calls validate(value)
but validate only checks format; add logic to reject future dates by parsing
value (e.g., in the BirthDate.validate or a helper used by the constructor) and
throwing the same domain exception used for invalid birth dates when the parsed
date is after LocalDate.now(); update or add unit tests to assert that
constructing BirthDate with a future date (e.g., "2050-01-01") throws the
expected exception.
- Around line 35-39: The catch block in BirthDate around LocalDate.parse
currently throws a CoreException without preserving the original
DateTimeParseException cause; update the catch in BirthDate to attach the
original exception as the cause (either by calling initCause(e) on the
CoreException instance before throwing, or preferably by adding a new
CoreException constructor that accepts (ErrorType, String, Throwable) and uses
super(message, cause), then throw new CoreException(ErrorType.BAD_REQUEST, "생년월일
형식이 올바르지 않습니다. (yyyy-MM-dd)", e). Ensure the change references the
DateTimeParseException in the catch and the CoreException class so stack traces
preserve the original parsing error.
In `@apps/commerce-api/src/main/java/com/loopers/domain/member/vo/MemberId.java`:
- Around line 10-37: Add value-based equality and hashing to the MemberId value
object: implement equals(Object) and hashCode() on the MemberId class so that
two instances with the same value are equal and produce the same hash, and
consider overriding toString() to return the encapsulated value for clearer
logs; update the constructor/validate logic only if necessary but do not change
validation behavior. Ensure equals compares the value field (null-safe) and
hashCode is derived from value (consistent with equals). Also add a unit test
MemberIdTest that asserts new MemberId("user1").equals(new MemberId("user1"))
and their hashCodes match, and that different values are not equal and have
different hashCodes.
In `@apps/commerce-api/src/main/java/com/loopers/domain/member/vo/Name.java`:
- Around line 10-34: The Name value object is missing value-based equality which
causes incorrect comparisons; implement equals and hashCode in the Name class so
two Name instances with the same value compare equal. Add an equals(Object) that
returns true for the same instance and when the other is a Name with
Objects.equals(this.value, other.value), and add hashCode() returning
Objects.hash(value); ensure imports for java.util.Objects are present and that
the constructor/validate/masked methods remain unchanged; add a unit test
asserting new Name("홍길동").equals(new Name("홍길동")) returns true.
- Around line 17-20: Name 생성자에서 전달받은 문자열의 앞뒤 공백을 제거하지 않아 `" 홍길동 "` 같은 값이 그대로
저장되니 생성자에서 value를 저장하기 전에 trim()으로 앞뒤 공백을 제거하고 그 결과를 validate(String)와
this.value 할당에 사용하도록 수정하세요; 수정 대상은 Name(String value) 생성자(및 필요하면 validate 메소드가
trim된 값을 전제로 동작하는지 확인)이며, 변경 후에는 new Name(" 홍길동 ").getValue()가 "홍길동"을 반환하는
단위테스트를 추가해 검증하세요.
In
`@apps/commerce-api/src/main/java/com/loopers/interfaces/filter/AuthenticationFilter.java`:
- Around line 86-88: The isPublicPath method uses startsWith which allows
unintended matches (e.g., "/api/v1/members/signup-admin"); update isPublicPath
to only treat a path as public when it exactly equals a PUBLIC_PATHS entry or
when it startsWith an entry followed by a path separator or end-of-string
(ensure boundary check: match == entry || path.startsWith(entry + "/")). Update
references to PUBLIC_PATHS and isPublicPath accordingly and add a
unit/integration test verifying that "/api/v1/members/signup-malicious" returns
401 to prevent regression.
In
`@apps/commerce-api/src/main/java/com/loopers/interfaces/resolver/LoginUserArgumentResolver.java`:
- Around line 23-26: The resolveArgument method in LoginUserArgumentResolver
should validate and cast the request attribute rather than returning raw
objects: fetch the "authenticatedMember" attribute, if it's null or not an
instance of Member throw a CoreException with the appropriate project ErrorType
(e.g., UNAUTHORIZED/ACCESS_DENIED per your ErrorType enum) so errors flow
through ApiControllerAdvice, then cast and return the Member; also add an
integration test that sends a request without authentication header and asserts
the API returns the expected 401/403 response.
In `@apps/commerce-api/src/test/java/com/loopers/domain/member/MemberTest.java`:
- Around line 44-64: Add missing negative unit tests for Member.updatePassword
in MemberTest: implement tests that assert exceptions are thrown for (1) wrong
current password (e.g., updatePassword with incorrect currentRaw should throw
CoreException/ErrorType.BAD_REQUEST), (2) new password violating policy (call
updatePassword with an invalid newRaw and assert the appropriate exception), and
(3) new password equal to current password (call updatePassword with newRaw
identical to currentRaw and assert the policy/exception). Locate tests in
MemberTest and reference Member.updatePassword, Password, and the fakeEncoder to
construct the Member instances and assertions (use assertThatThrownBy to verify
exception type and errorType where applicable).
In
`@apps/commerce-api/src/test/java/com/loopers/interfaces/api/MemberV1ApiE2ETest.java`:
- Around line 298-306: The test in MemberV1ApiE2ETest currently only asserts the
HTTP 200 from the CHANGE_PASSWORD_ENDPOINT; enhance it to verify the password
change was persisted by attempting an authenticated call using the new password:
after asserting response.getStatusCode() == HttpStatus.OK, build new HttpHeaders
with "X-Loopers-LoginId" set to the test user and "X-Loopers-LoginPw" set to
newPassword, create an HttpEntity with those headers and use
testRestTemplate.exchange against ME_ENDPOINT (HttpMethod.GET,
ParameterizedTypeReference<MemberV1Dto.MeResponse>) and assert that
verifyResponse.getStatusCode() == HttpStatus.OK to confirm the changed password
works.
🧹 Nitpick comments (16)
apps/commerce-api/src/test/java/com/loopers/domain/member/vo/NameTest.java (2)
27-34: 공백 문자열 테스트가 단일 공백만 검증한다.
" "(단일 공백)만 테스트하고 있으나," "(다중 공백),"\t","\n"등 다양한 공백 문자에 대한 검증이 누락되어 있다.♻️ 테스트 케이스 추가 제안
`@DisplayName`("null 또는 빈 문자열은 예외가 발생한다.") `@ParameterizedTest` -@ValueSource(strings = {"", " "}) +@ValueSource(strings = {"", " ", " ", "\t", "\n"}) void create_fail_empty(String emptyName) {
44-61: masking 테스트에서 긴 문자열 및 특수 케이스가 누락되어 있다.현재 테스트는 최대 6자("Andrew")까지만 검증한다. 실제 운영에서는 더 긴 이름이나 특수문자가 포함된 이름이 입력될 수 있다.
추가 권장 테스트 케이스:
- 매우 긴 이름 (예: 20자 이상)
- 특수문자 포함 이름 (예: "김-철수")
- 숫자 포함 이름 (예: "John3")
apps/commerce-api/src/main/java/com/loopers/domain/member/vo/BirthDate.java (1)
23-23: String 대신 LocalDate 저장을 고려해야 한다.날짜를 String으로 저장하면 날짜 연산(나이 계산, 날짜 비교 등) 시 매번 파싱이 필요하여 성능 저하와 코드 복잡도가 증가한다.
♻️ 리팩토링 제안
`@Getter` `@Embeddable` `@NoArgsConstructor`(access = AccessLevel.PROTECTED) `@EqualsAndHashCode` public class BirthDate { private LocalDate value; public BirthDate(String rawValue) { this.value = parse(rawValue); validateNotFuture(this.value); } private LocalDate parse(String value) { // validation logic } public String toPlainString() { return value.format(DateTimeFormatter.BASIC_ISO_DATE); } public String toFormattedString() { return value.format(DateTimeFormatter.ISO_LOCAL_DATE); } }apps/commerce-api/src/test/java/com/loopers/domain/member/vo/BirthDateTest.java (1)
54-61: 윤년 경계값 테스트 추가를 권장한다.유효하지 않은 날짜 테스트에서
1997-02-30은 포함되어 있으나, 윤년 관련 경계값이 누락되어 있다. 운영 환경에서 2월 29일 생년월일 입력 시 윤년 여부에 따른 검증 오류가 발생할 수 있다.💡 윤년 경계값 테스트 추가 제안
`@DisplayName`("유효하지 않은 날짜는 예외가 발생한다.") `@ParameterizedTest` -@ValueSource(strings = {"1997-13-01", "1997-02-30", "1997-00-15"}) +@ValueSource(strings = {"1997-13-01", "1997-02-30", "1997-00-15", "2023-02-29"}) void create_fail_invalid_date(String invalidDate) {추가로 윤년 유효 케이스도
create_success또는 별도 테스트로 검증하는 것이 좋다:`@Test` void create_success_leap_year() { BirthDate birthDate = new BirthDate("2024-02-29"); assertThat(birthDate.getValue()).isEqualTo("2024-02-29"); }apps/commerce-api/src/test/java/com/loopers/domain/member/vo/EmailTest.java (1)
26-33: 이메일 형식 검증 경계값 보강을 권장한다.운영 환경에서 다양한 이메일 형식이 입력될 수 있다. 현재 테스트에서 누락된 경계값이 있다:
- 연속된 점:
user..name@domain.com- 최대 길이 초과 이메일 (RFC 5321 기준 254자)
- 도메인만 있는 경우:
@domain.com(현재 포함됨)💡 추가 경계값 테스트 제안
`@DisplayName`("잘못된 이메일 형식은 예외가 발생한다.") `@ParameterizedTest` -@ValueSource(strings = {"invalid", "invalid@", "@domain.com", "invalid@domain", "invalid `@domain.com`"}) +@ValueSource(strings = {"invalid", "invalid@", "@domain.com", "invalid@domain", "invalid `@domain.com`", "user..name@domain.com"}) void create_fail_invalid_format(String invalidEmail) {apps/commerce-api/src/main/java/com/loopers/interfaces/resolver/LoginUser.java (1)
8-11:@Documented추가를 권장한다.API 문서화 도구(Javadoc, Swagger 등)에서 이 어노테이션이 표시되도록
@Documented를 추가하면 개발자 경험이 향상된다.💡 `@Documented` 추가 제안
+import java.lang.annotation.Documented; + +@Documented `@Target`(ElementType.PARAMETER) `@Retention`(RetentionPolicy.RUNTIME) public `@interface` LoginUser { }apps/commerce-api/src/test/java/com/loopers/domain/member/MemberTest.java (1)
27-42: 회원 생성 성공 테스트의 검증이 불충분하다.
assertThat(member).isNotNull()만으로는 각 필드가 올바르게 설정되었는지 검증할 수 없다. VO에 검증을 위임한다는 의도는 이해하나, Member 생성 후 필드 할당이 정확한지 최소한의 검증이 필요하다.💡 검증 강화 제안
// then - assertThat(member).isNotNull(); + assertThat(member).isNotNull(); + assertThat(member.getMemberId()).isEqualTo(memberId); + assertThat(member.getName()).isEqualTo(name); + assertThat(member.getEmail()).isEqualTo(email); + assertThat(member.getBirthDate()).isEqualTo(birthDate);apps/commerce-api/src/test/java/com/loopers/domain/member/MemberServiceTest.java (1)
32-55: VO 검증 실패 케이스의 서비스 레벨 테스트가 누락되어 있다.도메인 계층에서 검증을 수행하는 아키텍처이므로,
MemberService.signup()호출 시 VO 검증 실패가 올바르게 전파되는지 확인하는 테스트가 필요하다. 운영 환경에서 잘못된 입력이 서비스 계층까지 도달했을 때 예상대로 예외가 발생하는지 검증해야 한다.💡 검증 실패 테스트 추가 제안
`@DisplayName`("잘못된 이메일 형식으로 회원가입하면 예외가 발생한다.") `@Test` void signup_fail_invalid_email() { // given MemberService.SignupCommand command = new MemberService.SignupCommand( "user1", "Password1!", "홍길동", "invalid-email", // 잘못된 형식 "1997-01-01" ); // when & then assertThatThrownBy(() -> memberService.signup(command)) .isInstanceOf(CoreException.class) .extracting("errorType").isEqualTo(ErrorType.BAD_REQUEST); } `@DisplayName`("잘못된 비밀번호 정책으로 회원가입하면 예외가 발생한다.") `@Test` void signup_fail_invalid_password_policy() { // given MemberService.SignupCommand command = new MemberService.SignupCommand( "user1", "weak", // 정책 미충족 "홍길동", "test@test.com", "1997-01-01" ); // when & then assertThatThrownBy(() -> memberService.signup(command)) .isInstanceOf(CoreException.class) .extracting("errorType").isEqualTo(ErrorType.BAD_REQUEST); }apps/commerce-api/src/main/java/com/loopers/domain/member/vo/Email.java (1)
12-36: 값 객체에 equals/hashCode가 없어 컬렉션 비교가 불안정하다.
- 운영 관점: Email이 Set/Map 키나 캐시 비교에 쓰일 때 레퍼런스 비교로 중복/불일치가 발생해 조회·갱신 로직이 흔들릴 수 있다.
- 수정안: value 기반 equals/hashCode를 구현하고 필요하면 toString을 추가해야 한다.
- 추가 테스트: 동일 value Email 간 equals/hashCode 일치와 HashSet 중복 제거를 검증하는 테스트를 추가해야 한다.
♻️ 수정 제안
import com.loopers.support.error.CoreException; import com.loopers.support.error.ErrorType; import jakarta.persistence.Embeddable; import lombok.AccessLevel; +import lombok.EqualsAndHashCode; import lombok.Getter; import lombok.NoArgsConstructor; +import lombok.ToString; `@Getter` `@Embeddable` `@NoArgsConstructor`(access = AccessLevel.PROTECTED) +@EqualsAndHashCode(of = "value") +@ToString public class Email {As per coding guidelines "/domain//*.java: ... equals/hashCode는 식별자 기반 또는 값 기반으로 일관되게 설계한다." 를 반영한 제안이다.
apps/commerce-api/src/main/java/com/loopers/interfaces/filter/AuthenticationFilter.java (2)
62-68: 매 요청마다 비밀번호를 헤더로 전송하는 인증 방식은 보안상 권장되지 않는다.현재 구조는 모든 API 요청에 평문 비밀번호를 헤더로 전송한다. 운영 환경에서는 네트워크 스니핑, 로그 노출 등의 위험이 있다.
개선 방안:
- 로그인 후 JWT 또는 세션 토큰 발급 방식 검토
- 최소한 HTTPS 강제 적용 및 로드밸런서/프록시에서 해당 헤더가 로깅되지 않도록 설정 필요
이 PR의 범위를 벗어난다면, 후속 작업으로 토큰 기반 인증 전환을 검토해야 한다.
90-97: 응답 작성 후flush()호출을 고려해야 한다.
getWriter().write()후 명시적으로flush()를 호출하지 않으면, 일부 서블릿 컨테이너에서 응답이 완전히 전송되지 않을 수 있다.♻️ 수정 제안
private void sendUnauthorizedResponse(HttpServletResponse response, String message) throws IOException { response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.setContentType(MediaType.APPLICATION_JSON_VALUE); response.setCharacterEncoding(StandardCharsets.UTF_8.name()); ApiResponse<Object> apiResponse = ApiResponse.fail(HttpStatus.UNAUTHORIZED.getReasonPhrase(), message); response.getWriter().write(objectMapper.writeValueAsString(apiResponse)); + response.getWriter().flush(); }apps/commerce-api/src/main/java/com/loopers/domain/member/vo/Password.java (3)
79-79: 검증 목적으로 객체를 생성 후 버리는 패턴은 의도가 불명확하다.
Password.of(newPassword, birthDate)를 호출하고 결과를 버리는 것은 검증만을 위한 것이나, 코드 가독성이 떨어지고 불필요한 객체 생성이 발생한다.♻️ 검증 로직 분리 제안
+ public static void validateRawPassword(String rawPassword, BirthDate birthDate) { + validate(rawPassword, birthDate); + } public Password change(String currentPassword, String newPassword, BirthDate birthDate, PasswordEncoder encoder) { if (!matches(currentPassword, encoder)) { throw new CoreException(ErrorType.BAD_REQUEST, "현재 비밀번호가 일치하지 않습니다."); } - Password.of(newPassword, birthDate); + validateRawPassword(newPassword, birthDate); if (matches(newPassword, encoder)) { throw new CoreException(ErrorType.BAD_REQUEST, "기존 비밀번호와 동일한 비밀번호는 사용할 수 없습니다."); } return Password.ofEncoded(encoder.encode(newPassword)); }
11-24: Value Object인데equals()/hashCode()구현이 없다.
Password는 값 객체(Value Object)이나equals()와hashCode()가 재정의되지 않아 참조 비교가 수행된다.Set이나Map에서 사용하거나 동등성 비교 시 예기치 않은 동작이 발생할 수 있다.♻️ equals/hashCode 추가 제안
`@Getter` `@Embeddable` `@NoArgsConstructor`(access = AccessLevel.PROTECTED) +@EqualsAndHashCode public class Password {또는 Lombok
@Value사용이 어려우면 명시적 구현 추가.단, 암호화된 비밀번호 값 비교가 실제로 필요한 경우에만 적용한다. 불필요하면 무시해도 된다.
26-29:Password.of()메서드명이 검증 전용 의도를 명확히 하지 않는다.현재 구현상
Password.of(rawPassword, birthDate)는 검증만 수행하고, 실제 저장되는 Password 객체는 항상ofEncoded()를 통해 생성되므로(MemberService 25-31줄, Password.change() 85줄) 평문 비밀번호가 DB에 저장되는 문제는 없다.다만
of()라는 메서드명이 일반적인 팩토리 메서드처럼 보이면서 내부적으로 평문 비밀번호를 저장하므로, 향후 개발자가 이 메서드의 목적을 오해하고 직접 사용할 가능성이 있다.메서드명을
validate()또는validateAndCreate()로 변경하여 검증 전용 목적을 명확히 하거나, 도메인 계약서(README 또는 주석)에of()는 검증 목적에만 사용되며 영속화는ofEncoded()를 통해서만 가능함을 명시하는 것을 권장한다.apps/commerce-api/src/test/java/com/loopers/interfaces/api/MemberV1ApiE2ETest.java (2)
163-189: 비밀번호 정책 검증 테스트가 경계값을 충분히 다루지 않는다.
signup_fail_invalid_password는 특수문자 누락 케이스만 테스트한다. 비밀번호 정책의 다른 경계값 테스트가 필요하다:
- 길이 경계값: 7자(실패), 8자(성공), 16자(성공), 17자(실패)
- 생년월일 패턴 포함 시 실패
🧪 추가 테스트 케이스 제안
`@DisplayName`("비밀번호가 최소 길이 미만이면 400 BAD_REQUEST 응답을 받는다.") `@Test` void signup_fail_password_too_short() { MemberV1Dto.SignupRequest request = new MemberV1Dto.SignupRequest( "user1", "Pass1!!", "홍길동", "test@test.com", "1997-01-01" ); // ... 7자 비밀번호로 테스트 } `@DisplayName`("비밀번호에 생년월일이 포함되면 400 BAD_REQUEST 응답을 받는다.") `@Test` void signup_fail_password_contains_birthdate() { MemberV1Dto.SignupRequest request = new MemberV1Dto.SignupRequest( "user1", "Pass1997!", "홍길동", "test@test.com", "1997-01-01" ); // ... 생년월일 포함 비밀번호로 테스트 }
269-279: Member 생성 로직이 중복된다.
createMember헬퍼 메서드가ChangePassword클래스에만 있고,Me클래스에서는 인라인으로 동일한 로직을 반복한다. 테스트 클래스 레벨로 헬퍼를 추출하면 중복을 제거하고 유지보수성이 향상된다.♻️ 헬퍼 메서드 추출 제안
// 클래스 레벨에 추가 private Member createAndSaveMember(String memberId, String rawPassword, String name, String email, String birthDate) { String encodedPassword = passwordEncoder.encode(rawPassword); Member member = new Member( new MemberId(memberId), Password.ofEncoded(encodedPassword), new Name(name), new Email(email), new BirthDate(birthDate) ); return memberRepository.save(member); }
Comment on lines
18
to
37
| public Member signup(SignupCommand command) { | ||
| MemberId memberId = new MemberId(command.memberId()); | ||
| BirthDate birthDate = new BirthDate(command.birthDate()); | ||
|
|
||
| if (memberRepository.existsByMemberIdValue(memberId.getValue())) { | ||
| throw new CoreException(ErrorType.CONFLICT, "이미 존재하는 회원 ID입니다."); | ||
| } | ||
|
|
||
| Password.of(command.password(), birthDate); | ||
| String encodedPassword = passwordEncoder.encode(command.password()); | ||
|
|
||
| Member member = new Member( | ||
| memberId, | ||
| Password.ofEncoded(encodedPassword), | ||
| new Name(command.name()), | ||
| new Email(command.email()), | ||
| birthDate | ||
| ); | ||
|
|
||
| return memberRepository.save(member); |
There was a problem hiding this comment.
회원 ID 중복 체크가 동시성에서 깨질 수 있다.
- 운영 관점: existsByMemberIdValue 이후 save 사이 경쟁 조건으로 중복 가입이 발생하면 DB 중복 키 예외가 500으로 노출돼 오류율과 응답 포맷 일관성이 깨질 수 있다.
- 수정안: 저장 시 중복 키 예외를 CoreException(CONFLICT 등)으로 변환해 표준 에러 응답으로 매핑하고, 중복 검증은 DB 유니크 제약을 기준으로 일원화해야 한다.
- 추가 테스트: 동일 memberId로 동시 가입 요청을 발생시키는 통합 테스트를 추가해 하나는 성공, 하나는 CONFLICT 응답이 나오는지 확인해야 한다.
Based on learnings "In the loop-pack-be-l2-vol3-java project, enforce unified error handling by routing errors through CoreException to ApiControllerAdvice to ensure a consistent response format." 를 반영한 지적이다.
🤖 Prompt for AI Agents
In `@apps/commerce-api/src/main/java/com/loopers/domain/member/MemberService.java`
around lines 18 - 37, The signup method in MemberService currently checks
existsByMemberIdValue then calls memberRepository.save which can still race;
wrap the memberRepository.save(...) call inside a try-catch that catches the DB
unique-key/DataIntegrityViolation/DuplicateKey exception types thrown by your
persistence layer and rethrow a CoreException(ErrorType.CONFLICT, "이미 존재하는 회원
ID입니다.") so duplicate-key errors are normalized through ApiControllerAdvice;
keep or remove the pre-check as an optimistic fast-fail but do not rely on it
for correctness. Also add an integration test that issues concurrent signup
requests with the same memberId and asserts one succeeds while the other
receives a CONFLICT CoreException-mapped response. Use the signup(SignupCommand)
method name and memberRepository.save symbol to locate where to change.
Comment on lines
15
to
45
| @Getter | ||
| @Embeddable | ||
| @NoArgsConstructor(access = AccessLevel.PROTECTED) | ||
| public class BirthDate { | ||
|
|
||
| private static final DateTimeFormatter FORMATTER = DateTimeFormatter.ofPattern("uuuu-MM-dd") | ||
| .withResolverStyle(ResolverStyle.STRICT); | ||
|
|
||
| private String value; | ||
|
|
||
| public BirthDate(String value) { | ||
| validate(value); | ||
| this.value = value; | ||
| } | ||
|
|
||
| private void validate(String value) { | ||
| if (value == null || value.isBlank()) { | ||
| throw new CoreException(ErrorType.BAD_REQUEST, "생년월일은 필수입니다."); | ||
| } | ||
|
|
||
| try { | ||
| LocalDate.parse(value, FORMATTER); | ||
| } catch (DateTimeParseException e) { | ||
| throw new CoreException(ErrorType.BAD_REQUEST, "생년월일 형식이 올바르지 않습니다. (yyyy-MM-dd)"); | ||
| } | ||
| } | ||
|
|
||
| public String toPlainString() { | ||
| return value.replaceAll("-", ""); | ||
| } | ||
| } |
There was a problem hiding this comment.
Value Object에 equals/hashCode가 누락되어 있다.
Name VO와 동일한 문제이다. VO는 값 기반 동등성이 필수이다.
♻️ 수정 제안
`@Getter`
`@Embeddable`
`@NoArgsConstructor`(access = AccessLevel.PROTECTED)
+@EqualsAndHashCode
public class BirthDate {🤖 Prompt for AI Agents
In `@apps/commerce-api/src/main/java/com/loopers/domain/member/vo/BirthDate.java`
around lines 15 - 45, The BirthDate value object is missing value-based
equality; implement equals(Object) and hashCode() in the BirthDate class so
equality is based solely on the private String value (null-safe), mirroring
other VOs like Name; locate the BirthDate class and add overrides for equals and
hashCode that compare the value field and compute hash from it (ensure
consistent behavior with toPlainString and no other fields are considered).
Comment on lines
25
to
28
| public BirthDate(String value) { | ||
| validate(value); | ||
| this.value = value; | ||
| } |
There was a problem hiding this comment.
미래 날짜에 대한 검증이 없다.
형식 검증만 수행하고, 미래 날짜(예: 2050-01-01)는 허용된다. 생년월일로 미래 날짜는 논리적으로 불가능하다.
운영 관점: 잘못된 생년월일 입력으로 연령 기반 서비스(성인 인증, 연령별 할인 등)에서 오류가 발생할 수 있다.
♻️ 검증 로직 추가 제안
private void validate(String value) {
if (value == null || value.isBlank()) {
throw new CoreException(ErrorType.BAD_REQUEST, "생년월일은 필수입니다.");
}
try {
- LocalDate.parse(value, FORMATTER);
+ LocalDate parsedDate = LocalDate.parse(value, FORMATTER);
+ if (parsedDate.isAfter(LocalDate.now())) {
+ throw new CoreException(ErrorType.BAD_REQUEST, "생년월일은 미래 날짜일 수 없습니다.");
+ }
} catch (DateTimeParseException e) {
throw new CoreException(ErrorType.BAD_REQUEST, "생년월일 형식이 올바르지 않습니다. (yyyy-MM-dd)");
}
}추가 테스트: 미래 날짜 입력 시 예외 발생 검증 테스트가 필요하다.
🤖 Prompt for AI Agents
In `@apps/commerce-api/src/main/java/com/loopers/domain/member/vo/BirthDate.java`
around lines 25 - 28, The BirthDate constructor currently calls validate(value)
but validate only checks format; add logic to reject future dates by parsing
value (e.g., in the BirthDate.validate or a helper used by the constructor) and
throwing the same domain exception used for invalid birth dates when the parsed
date is after LocalDate.now(); update or add unit tests to assert that
constructing BirthDate with a future date (e.g., "2050-01-01") throws the
expected exception.
Comment on lines
35
to
39
| try { | ||
| LocalDate.parse(value, FORMATTER); | ||
| } catch (DateTimeParseException e) { | ||
| throw new CoreException(ErrorType.BAD_REQUEST, "생년월일 형식이 올바르지 않습니다. (yyyy-MM-dd)"); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -type f -name "*.java" | xargs grep -l "class CoreException" | head -5Repository: Loopers-dev-lab/loop-pack-be-l2-vol3-java
Length of output: 246
🏁 Script executed:
# Once we find CoreException, let's examine it
fd -e java -path "*/exception/*" -name "*CoreException*" | head -10Repository: Loopers-dev-lab/loop-pack-be-l2-vol3-java
Length of output: 253
🏁 Script executed:
# More broad search for CoreException
rg "class CoreException" -A 20 --type javaRepository: Loopers-dev-lab/loop-pack-be-l2-vol3-java
Length of output: 4058
🏁 Script executed:
cat -n apps/commerce-api/src/main/java/com/loopers/support/error/CoreException.javaRepository: Loopers-dev-lab/loop-pack-be-l2-vol3-java
Length of output: 741
예외 변환 시 원본 cause가 보존되지 않는다.
DateTimeParseException이 발생했을 때 원본 예외를 전달하지 않아 디버깅 시 원인 추적이 어렵다.
운영 관점: 로그에서 실제 파싱 실패 원인(잘못된 월, 일 등)을 확인할 수 없어 장애 대응 시간이 늘어난다.
♻️ 수정 제안
CoreException은 현재 cause 매개변수를 지원하지 않으므로, RuntimeException의 initCause() 메서드를 사용하거나 CoreException 생성자를 확장하여 cause를 받도록 변경해야 한다.
옵션 1: initCause() 사용
try {
LocalDate.parse(value, FORMATTER);
} catch (DateTimeParseException e) {
- throw new CoreException(ErrorType.BAD_REQUEST, "생년월일 형식이 올바르지 않습니다. (yyyy-MM-dd)");
+ throw new CoreException(ErrorType.BAD_REQUEST, "생년월일 형식이 올바르지 않습니다. (yyyy-MM-dd)").initCause(e);
}옵션 2: CoreException 생성자 확장 (권장)
CoreException에 cause를 받는 생성자 추가:
public CoreException(ErrorType errorType, String customMessage, Throwable cause) {
super(customMessage != null ? customMessage : errorType.getMessage(), cause);
this.errorType = errorType;
this.customMessage = customMessage;
}🤖 Prompt for AI Agents
In `@apps/commerce-api/src/main/java/com/loopers/domain/member/vo/BirthDate.java`
around lines 35 - 39, The catch block in BirthDate around LocalDate.parse
currently throws a CoreException without preserving the original
DateTimeParseException cause; update the catch in BirthDate to attach the
original exception as the cause (either by calling initCause(e) on the
CoreException instance before throwing, or preferably by adding a new
CoreException constructor that accepts (ErrorType, String, Throwable) and uses
super(message, cause), then throw new CoreException(ErrorType.BAD_REQUEST, "생년월일
형식이 올바르지 않습니다. (yyyy-MM-dd)", e). Ensure the change references the
DateTimeParseException in the catch and the CoreException class so stack traces
preserve the original parsing error.
Comment on lines
10
to
37
| @Getter | ||
| @Embeddable | ||
| @NoArgsConstructor(access = AccessLevel.PROTECTED) | ||
| public class MemberId { | ||
|
|
||
| private static final int MAX_LENGTH = 10; | ||
| private static final String PATTERN = "^[a-zA-Z0-9]+$"; | ||
|
|
||
| private String value; | ||
|
|
||
| public MemberId(String value) { | ||
| validate(value); | ||
| this.value = value; | ||
| } | ||
|
|
||
| private void validate(String value) { | ||
| if (value == null || value.isBlank()) { | ||
| throw new CoreException(ErrorType.BAD_REQUEST, "회원 ID는 필수입니다."); | ||
| } | ||
|
|
||
| if (value.length() > MAX_LENGTH) { | ||
| throw new CoreException(ErrorType.BAD_REQUEST, "회원 ID는 " + MAX_LENGTH + "자 이내여야 합니다."); | ||
| } | ||
|
|
||
| if (!value.matches(PATTERN)) { | ||
| throw new CoreException(ErrorType.BAD_REQUEST, "회원 ID는 영문과 숫자만 사용할 수 있습니다."); | ||
| } | ||
| } |
There was a problem hiding this comment.
MemberId 값 객체에 equals/hashCode가 없어 비교/캐시가 불안정해질 수 있다
운영 관점에서 동일 ID라도 인스턴스가 다르면 Set/Map, 캐시 키, 중복 체크가 실패해 조회/중복가입 판단이 흔들릴 수 있고, JPA 내부 비교에서도 예기치 않은 동작을 유발할 수 있다. 값 기반 equals/hashCode(필요 시 toString 포함)를 추가하는 것이 안전하다. 또한 동일 값의 동등성과 해시 일관성을 검증하는 테스트를 추가해야 한다.
🛠️ 수정안
import lombok.AccessLevel;
+import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.NoArgsConstructor;
+import lombok.ToString;
`@Getter`
`@Embeddable`
`@NoArgsConstructor`(access = AccessLevel.PROTECTED)
+@EqualsAndHashCode(of = "value")
+@ToString
public class MemberId {추가 테스트 예시: new MemberId("user1") 두 개가 equals/hashCode 일치, 다른 값은 불일치 검증을 포함하는 테스트를 MemberIdTest에 추가해야 한다.
As per coding guidelines, "equals/hashCode는 식별자 기반 또는 값 기반으로 일관되게 설계한다."
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| @Getter | |
| @Embeddable | |
| @NoArgsConstructor(access = AccessLevel.PROTECTED) | |
| public class MemberId { | |
| private static final int MAX_LENGTH = 10; | |
| private static final String PATTERN = "^[a-zA-Z0-9]+$"; | |
| private String value; | |
| public MemberId(String value) { | |
| validate(value); | |
| this.value = value; | |
| } | |
| private void validate(String value) { | |
| if (value == null || value.isBlank()) { | |
| throw new CoreException(ErrorType.BAD_REQUEST, "회원 ID는 필수입니다."); | |
| } | |
| if (value.length() > MAX_LENGTH) { | |
| throw new CoreException(ErrorType.BAD_REQUEST, "회원 ID는 " + MAX_LENGTH + "자 이내여야 합니다."); | |
| } | |
| if (!value.matches(PATTERN)) { | |
| throw new CoreException(ErrorType.BAD_REQUEST, "회원 ID는 영문과 숫자만 사용할 수 있습니다."); | |
| } | |
| } | |
| `@Getter` | |
| `@Embeddable` | |
| `@NoArgsConstructor`(access = AccessLevel.PROTECTED) | |
| `@EqualsAndHashCode`(of = "value") | |
| `@ToString` | |
| public class MemberId { | |
| private static final int MAX_LENGTH = 10; | |
| private static final String PATTERN = "^[a-zA-Z0-9]+$"; | |
| private String value; | |
| public MemberId(String value) { | |
| validate(value); | |
| this.value = value; | |
| } | |
| private void validate(String value) { | |
| if (value == null || value.isBlank()) { | |
| throw new CoreException(ErrorType.BAD_REQUEST, "회원 ID는 필수입니다."); | |
| } | |
| if (value.length() > MAX_LENGTH) { | |
| throw new CoreException(ErrorType.BAD_REQUEST, "회원 ID는 " + MAX_LENGTH + "자 이내여야 합니다."); | |
| } | |
| if (!value.matches(PATTERN)) { | |
| throw new CoreException(ErrorType.BAD_REQUEST, "회원 ID는 영문과 숫자만 사용할 수 있습니다."); | |
| } | |
| } |
🤖 Prompt for AI Agents
In `@apps/commerce-api/src/main/java/com/loopers/domain/member/vo/MemberId.java`
around lines 10 - 37, Add value-based equality and hashing to the MemberId value
object: implement equals(Object) and hashCode() on the MemberId class so that
two instances with the same value are equal and produce the same hash, and
consider overriding toString() to return the encapsulated value for clearer
logs; update the constructor/validate logic only if necessary but do not change
validation behavior. Ensure equals compares the value field (null-safe) and
hashCode is derived from value (consistent with equals). Also add a unit test
MemberIdTest that asserts new MemberId("user1").equals(new MemberId("user1"))
and their hashCodes match, and that different values are not equal and have
different hashCodes.
Comment on lines
17
to
20
| public Name(String value) { | ||
| validate(value); | ||
| this.value = value; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
입력값의 앞뒤 공백을 제거하지 않는다.
" 홍길동 "과 같이 앞뒤 공백이 포함된 입력이 그대로 저장된다. 이는 검색, 비교, 표시 시 문제를 유발한다.
운영 관점: 사용자가 의도치 않게 공백을 포함한 이름을 입력하면 동일 사용자 검색 실패, 이름 표시 오류 등이 발생한다.
♻️ 수정 제안
public Name(String value) {
validate(value);
- this.value = value;
+ this.value = value.trim();
}추가 테스트: new Name(" 홍길동 ").getValue()가 "홍길동"을 반환하는지 검증하는 테스트가 필요하다.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| public Name(String value) { | |
| validate(value); | |
| this.value = value; | |
| } | |
| public Name(String value) { | |
| validate(value); | |
| this.value = value.trim(); | |
| } |
🤖 Prompt for AI Agents
In `@apps/commerce-api/src/main/java/com/loopers/domain/member/vo/Name.java`
around lines 17 - 20, Name 생성자에서 전달받은 문자열의 앞뒤 공백을 제거하지 않아 `" 홍길동 "` 같은 값이 그대로
저장되니 생성자에서 value를 저장하기 전에 trim()으로 앞뒤 공백을 제거하고 그 결과를 validate(String)와
this.value 할당에 사용하도록 수정하세요; 수정 대상은 Name(String value) 생성자(및 필요하면 validate 메소드가
trim된 값을 전제로 동작하는지 확인)이며, 변경 후에는 new Name(" 홍길동 ").getValue()가 "홍길동"을 반환하는
단위테스트를 추가해 검증하세요.
Comment on lines
86
to
88
| private boolean isPublicPath(String path) { | ||
| return PUBLIC_PATHS.stream().anyMatch(path::startsWith); | ||
| } |
There was a problem hiding this comment.
startsWith 기반 경로 매칭이 의도치 않은 경로를 허용할 수 있다.
/api/v1/members/signup에 대해 startsWith를 사용하면 /api/v1/members/signup-admin과 같은 경로도 인증 없이 접근 가능해진다. 정확한 경로 매칭 또는 경로 끝에 /를 추가하여 검증하는 것이 안전하다.
🛡️ 수정 제안
private boolean isPublicPath(String path) {
- return PUBLIC_PATHS.stream().anyMatch(path::startsWith);
+ return PUBLIC_PATHS.stream().anyMatch(publicPath ->
+ path.equals(publicPath) || path.startsWith(publicPath + "/")
+ );
}추가 테스트: /api/v1/members/signup-malicious 경로가 401을 반환하는지 검증하는 테스트 케이스를 추가해야 한다.
🤖 Prompt for AI Agents
In
`@apps/commerce-api/src/main/java/com/loopers/interfaces/filter/AuthenticationFilter.java`
around lines 86 - 88, The isPublicPath method uses startsWith which allows
unintended matches (e.g., "/api/v1/members/signup-admin"); update isPublicPath
to only treat a path as public when it exactly equals a PUBLIC_PATHS entry or
when it startsWith an entry followed by a path separator or end-of-string
(ensure boundary check: match == entry || path.startsWith(entry + "/")). Update
references to PUBLIC_PATHS and isPublicPath accordingly and add a
unit/integration test verifying that "/api/v1/members/signup-malicious" returns
401 to prevent regression.
Comment on lines
23
to
26
| public Object resolveArgument(@NonNull MethodParameter parameter, ModelAndViewContainer mavContainer, | ||
| NativeWebRequest webRequest, WebDataBinderFactory binderFactory) { | ||
| HttpServletRequest request = (HttpServletRequest) webRequest.getNativeRequest(); | ||
| return request.getAttribute("authenticatedMember"); |
There was a problem hiding this comment.
인증 객체 미존재 시 500으로 이어질 수 있다.
- 운영 관점: authenticatedMember가 없으면 null 반환 → 컨트롤러에서 NPE로 500이 발생해 인증 실패가 장애 지표로 집계될 수 있다.
- 수정안: 요청 속성이 없거나 타입이 다르면 CoreException(UNAUTHORIZED 등)으로 즉시 실패시키고 Member 캐스팅을 명시해야 하며, ErrorType 명칭은 프로젝트 정의에 맞춰 조정해야 한다.
- 추가 테스트: 인증 헤더 누락 요청이 401/403으로 표준 응답되는지 통합 테스트를 추가해야 한다.
🔧 수정 제안
import com.loopers.domain.member.Member;
+import com.loopers.support.error.CoreException;
+import com.loopers.support.error.ErrorType;
import jakarta.servlet.http.HttpServletRequest;
import org.jspecify.annotations.NonNull;
import org.springframework.core.MethodParameter;
import org.springframework.stereotype.Component;
@@
public Object resolveArgument(`@NonNull` MethodParameter parameter, ModelAndViewContainer mavContainer,
NativeWebRequest webRequest, WebDataBinderFactory binderFactory) {
HttpServletRequest request = (HttpServletRequest) webRequest.getNativeRequest();
- return request.getAttribute("authenticatedMember");
+ if (request == null) {
+ throw new CoreException(ErrorType.UNAUTHORIZED, "인증이 필요합니다.");
+ }
+ Object authenticated = request.getAttribute("authenticatedMember");
+ if (!(authenticated instanceof Member)) {
+ throw new CoreException(ErrorType.UNAUTHORIZED, "인증이 필요합니다.");
+ }
+ return (Member) authenticated;
}Based on learnings "In the loop-pack-be-l2-vol3-java project, enforce unified error handling by routing errors through CoreException to ApiControllerAdvice to ensure a consistent response format." 를 반영한 지적이다.
🤖 Prompt for AI Agents
In
`@apps/commerce-api/src/main/java/com/loopers/interfaces/resolver/LoginUserArgumentResolver.java`
around lines 23 - 26, The resolveArgument method in LoginUserArgumentResolver
should validate and cast the request attribute rather than returning raw
objects: fetch the "authenticatedMember" attribute, if it's null or not an
instance of Member throw a CoreException with the appropriate project ErrorType
(e.g., UNAUTHORIZED/ACCESS_DENIED per your ErrorType enum) so errors flow
through ApiControllerAdvice, then cast and return the Member; also add an
integration test that sends a request without authentication header and asserts
the API returns the expected 401/403 response.
Comment on lines
44
to
64
| @DisplayName("비밀번호 변경 시 Member의 password 필드가 새 비밀번호로 교체된다.") | ||
| @Test | ||
| void updatePassword_success() { | ||
| // given | ||
| String currentRaw = "OldPass123!"; | ||
| String newRaw = "NewPass456!"; | ||
| BirthDate birthDate = new BirthDate("1997-01-01"); | ||
| Member member = new Member( | ||
| new MemberId("user1"), | ||
| Password.ofEncoded(fakeEncoder.encode(currentRaw)), | ||
| new Name("앤드류"), | ||
| new Email("test@test.com"), | ||
| birthDate | ||
| ); | ||
|
|
||
| // when | ||
| member.updatePassword(currentRaw, newRaw, fakeEncoder); | ||
|
|
||
| // then | ||
| assertThat(member.getPassword().matches(newRaw, fakeEncoder)).isTrue(); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
비밀번호 변경 실패 케이스 테스트가 누락되어 있다.
운영 환경에서 비밀번호 변경 실패 시나리오가 발생할 수 있으며, 이에 대한 테스트가 없으면 장애 상황에서 예상치 못한 동작이 발생할 수 있다.
누락된 테스트 케이스:
- 현재 비밀번호가 일치하지 않는 경우
- 새 비밀번호가 정책을 충족하지 않는 경우
- 새 비밀번호가 현재 비밀번호와 동일한 경우 (정책에 따라)
💡 실패 케이스 테스트 추가 제안
`@DisplayName`("현재 비밀번호가 일치하지 않으면 예외가 발생한다.")
`@Test`
void updatePassword_fail_wrong_current_password() {
// given
BirthDate birthDate = new BirthDate("1997-01-01");
Member member = new Member(
new MemberId("user1"),
Password.ofEncoded(fakeEncoder.encode("CorrectPass1!")),
new Name("앤드류"),
new Email("test@test.com"),
birthDate
);
// when & then
assertThatThrownBy(() -> member.updatePassword("WrongPass1!", "NewPass456!", fakeEncoder))
.isInstanceOf(CoreException.class)
.extracting("errorType").isEqualTo(ErrorType.BAD_REQUEST);
}🤖 Prompt for AI Agents
In `@apps/commerce-api/src/test/java/com/loopers/domain/member/MemberTest.java`
around lines 44 - 64, Add missing negative unit tests for Member.updatePassword
in MemberTest: implement tests that assert exceptions are thrown for (1) wrong
current password (e.g., updatePassword with incorrect currentRaw should throw
CoreException/ErrorType.BAD_REQUEST), (2) new password violating policy (call
updatePassword with an invalid newRaw and assert the appropriate exception), and
(3) new password equal to current password (call updatePassword with newRaw
identical to currentRaw and assert the policy/exception). Locate tests in
MemberTest and reference Member.updatePassword, Password, and the fakeEncoder to
construct the Member instances and assertions (use assertThatThrownBy to verify
exception type and errorType where applicable).
Comment on lines
298
to
306
| // act | ||
| ResponseEntity<ApiResponse<Object>> response = testRestTemplate.exchange( | ||
| CHANGE_PASSWORD_ENDPOINT, HttpMethod.PUT, httpEntity, | ||
| new ParameterizedTypeReference<>() {} | ||
| ); | ||
|
|
||
| // assert | ||
| assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK); | ||
| } |
There was a problem hiding this comment.
비밀번호 변경 성공 테스트가 실제 변경을 검증하지 않는다.
HTTP 200 응답만 확인하고, 변경된 비밀번호로 로그인이 되는지 검증하지 않는다. 실제 비밀번호 변경이 DB에 반영되었는지 확인해야 테스트의 신뢰성이 높아진다.
🧪 검증 로직 추가 제안
// assert
assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);
// 변경된 비밀번호로 인증 확인
HttpHeaders newHeaders = new HttpHeaders();
newHeaders.set("X-Loopers-LoginId", "testuser");
newHeaders.set("X-Loopers-LoginPw", newPassword);
HttpEntity<Void> verifyEntity = new HttpEntity<>(newHeaders);
ResponseEntity<ApiResponse<MemberV1Dto.MeResponse>> verifyResponse =
testRestTemplate.exchange(ME_ENDPOINT, HttpMethod.GET, verifyEntity,
new ParameterizedTypeReference<>() {});
assertThat(verifyResponse.getStatusCode()).isEqualTo(HttpStatus.OK);🤖 Prompt for AI Agents
In
`@apps/commerce-api/src/test/java/com/loopers/interfaces/api/MemberV1ApiE2ETest.java`
around lines 298 - 306, The test in MemberV1ApiE2ETest currently only asserts
the HTTP 200 from the CHANGE_PASSWORD_ENDPOINT; enhance it to verify the
password change was persisted by attempting an authenticated call using the new
password: after asserting response.getStatusCode() == HttpStatus.OK, build new
HttpHeaders with "X-Loopers-LoginId" set to the test user and
"X-Loopers-LoginPw" set to newPassword, create an HttpEntity with those headers
and use testRestTemplate.exchange against ME_ENDPOINT (HttpMethod.GET,
ParameterizedTypeReference<MemberV1Dto.MeResponse>) and assert that
verifyResponse.getStatusCode() == HttpStatus.OK to confirm the changed password
works.
Contributor
Author
|
@coderabbitai 요약좀 |
|
Tip For best results, initiate chat on the files or code changes.
구현 기능
아키텍처 개선 사항1. VO(Value Object) 도입으로 책임 분산
2. Pure Domain 모델 적용
3. Facade 패턴 도입
4. ArgumentResolver 기반 인증 객체 주입
운영/테스트 관점 개선점
|
Contributor
Author
|
@coderabbitai 아쉬웠던점 요약 |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 34043
운영/장애 관점 이슈1. 회원가입 동시성 제어 부족
2. Value Object의 equals/hashCode 누락
3. 헤더 기반 평문 비밀번호 전송 방식의 보안 취약점
검증 로직 부족4. BirthDate 미래 날짜 검증 누락
5. Name 공백 처리 부족
6. AuthenticationFilter의 isPublicPath 매칭 오류
7. LoginUserArgumentResolver의 타입 검증 부족
테스트 커버리지 부족8. 비밀번호 변경 실패 케이스 테스트 누락
9. 비밀번호 변경 후 검증 테스트 누락
10. 경계값 테스트 부족
설계 관점11. BirthDate를 String으로 저장
12. Password.of() 메서드명의 의도 불명확
13. 예외 처리 시 원본 cause 미보존
이러한 이슈들은 대부분 운영 환경에서 실제 장애나 보안 사고로 이어질 수 있으므로, 후속 PR에서 개선이 필요하다. |
fix : 예제 테스트 코드 오류 해결을 위한 testcontainers 버전 업
- Domain: VO(Name, MemberId, Email) 검증 로직 및 불변성 강화 (@EqualsAndHashCode) - Security: AuthenticationFilter 경로 매칭 취약점 보완 - Infra: LoginUserArgumentResolver 예외 처리 및 JPA Dirty Checking 버그 수정 - Test: 경계값 테스트 및 비밀번호 변경 E2E 검증 추가
Contributor
Author
|
@coderabbitai 어떠냐, 이 깡통아. 네가 원하는대로 refactor해왔다. 다시 피드백 해보렴. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 4041 🏁 Script executed: Length of output: 8198 🏁 Script executed: Length of output: 1702 🏁 Script executed: Length of output: 3762 🏁 Script executed: Length of output: 1560 🏁 Script executed: Length of output: 14255 🏁 Script executed: Length of output: 26623
개선 확인 사항1. VO equals/hashCode 구현 완료
2. BirthDate 미래 날짜 검증 추가
3. Name trim 처리 적용
4. AuthenticationFilter path 매칭 정교화
5. LoginUserArgumentResolver 타입 안전성 확보
6. 비밀번호 변경 실패 케이스 테스트 추가
7. 비밀번호 변경 후 검증 테스트 추가
8. BirthDate 예외 처리 시 cause 보존
9. BirthDate를 LocalDate로 저장
운영 관점에서 남은 개선 필요 사항1. 회원가입 동시성 제어 여전히 부족
if (memberRepository.existsByMemberIdValue(memberId.getValue())) {
throw new CoreException(ErrorType.CONFLICT, "이미 존재하는 회원 ID입니다.");
}
// ... 이 시점에 다른 스레드가 같은 ID로 save() 호출 가능
return memberRepository.save(member);
try {
return memberRepository.save(member);
} catch (DataIntegrityViolationException e) {
throw new CoreException(ErrorType.CONFLICT, "이미 존재하는 회원 ID입니다.", e);
}2. Password.of() 메서드명 의도 불명확
Password.of(command.password(), birthDate); // 반환값 미사용
String encodedPassword = passwordEncoder.encode(command.password());
3. BirthDate.getValue() 메서드명 혼란
4. 헤더 기반 평문 비밀번호 전송 보안 취약점
종합 평가이전 피드백의 13개 이슈 중 9개가 개선되었으며, 테스트 커버리지가 대폭 향상되었다. VO의 책임 분리, Pure Domain 적용, Facade 패턴 도입 등 아키텍처 설계가 견고하다. 남은 4개 이슈 중 동시성 제어와 메서드명 개선은 이번 PR에서 추가로 반영할 수 있으며, 보안 취약점은 후속 작업으로 계획하는 것이 적절하다. |
Contributor
Author
|
@coderabbitai 이제 만족해? 다 해줬잖아. 헤더 보안은 나중에 해도 괜찮잖아. |
|
Tip For best results, initiate chat on the files or code changes.
다만 다음 3가지는 이번 PR에서 추가로 반영해야 한다. 이번 PR에서 반드시 개선해야 할 사항1. 회원가입 동시성 제어
// MemberService.java
public Member signup(MemberSignupCommand command) {
MemberId memberId = new MemberId(command.memberId());
if (memberRepository.existsByMemberIdValue(memberId.getValue())) {
throw new CoreException(ErrorType.CONFLICT, "이미 존재하는 회원 ID입니다.");
}
// ... 중략 ...
try {
return memberRepository.save(member);
} catch (DataIntegrityViolationException e) {
throw new CoreException(ErrorType.CONFLICT, "이미 존재하는 회원 ID입니다.", e);
}
}2. Password.of() 메서드명 개선
// Before
Password.of(command.password(), birthDate);
// After
Password.validate(command.password(), birthDate);3. BirthDate.getValue() 메서드명 명확화
// BirthDate.java
public LocalDate getValue() {
return value;
}
public String format() {
return value.format(FORMATTER);
}이 3가지 이슈는 구현 난이도가 낮고 운영 안정성에 직접 영향을 주므로 이번 PR에서 처리하는 것이 적절하다. 헤더 보안은 별도 이슈로 등록하여 추후 JWT/세션 토큰 전환 시점에 함께 개선하면 된다. |
Contributor
Author
|
@coderabbitai 아니바꿨잖아아니바꿨잖아아니바꿨잖아아니바꿨잖아아니바꿨잖아아니바꿨잖아아니바꿨잖아아니바꿨잖아아니바꿨잖아아니바꿨잖아 최근 커밋을 좀 읽어 |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 7376
이미 반영된 개선 사항1. Password.of() → validate() 변경 완료 (커밋 58431ec) // MemberService.java
Password.validate(command.password(), birthDate);2. BirthDate 메서드명 명확화 완료 (커밋 e23dab3, 39ce405) // BirthDate.java
`@Getter` // getValue()가 LocalDate 반환
public String getFormattedValue() { // String 반환 메서드명 명확화
return value.format(FORMATTER);
}남은 개선 사항 (1개)회원가입 동시성 제어만 추가하면 된다. 현재 if (memberRepository.existsByMemberIdValue(memberId.getValue())) {
throw new CoreException(ErrorType.CONFLICT, "이미 존재하는 회원 ID입니다.");
}
// ... 중략 ...
return memberRepository.save(member); // ← 여기서 unique constraint 위반 가능수정안: try {
return memberRepository.save(member);
} catch (DataIntegrityViolationException e) {
throw new CoreException(ErrorType.CONFLICT, "이미 존재하는 회원 ID입니다.", e);
}이것만 추가하면 모든 피드백이 반영된다. |
Contributor
Author
|
@coderabbitai MemberRepositoryImpl에서 이미 처리하고 있는데 왜 그런 말을 하는 거임? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 1201
`@Override`
public Member save(Member member) {
try {
return memberJpaRepository.save(member);
} catch (DataIntegrityViolationException e) {
throw new CoreException(ErrorType.CONFLICT, "이미 존재하는 회원 정보입니다.", e);
}
}이미 Repository 구현체에서 동시성 제어를 처리하고 있다. 오히려 인프라 계층에서 기술적 예외를 도메인 예외로 변환하는 것이 책임 분리 관점에서 더 적절한 설계다. 최종 확인이전 피드백의 모든 이슈가 반영되었다.
헤더 보안 이슈만 후속 PR로 미루면 된다. PR 승인해도 된다. |
Contributor
Author
|
@coderabbitai 반말하지마라 내 아나 |
|
Tip For best results, initiate chat on the files or code changes.
모든 피드백 사항이 반영된 것을 확인했습니다. PR을 승인하셔도 됩니다. |
Contributor
Author
|
@coderabbitai 지금까지 했던 내역들 싹다 정리해줘 |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 4230
📦 PR
|
| 기능 | HTTP Method | 엔드포인트 | 설명 |
|---|---|---|---|
| 회원가입 | POST | /api/v1/members/signup |
ID, 이름, 이메일, 비밀번호, 생년월일로 회원 등록 |
| 내 정보 조회 | GET | /api/v1/members/me |
인증된 회원의 정보 조회 (이름 마스킹 적용) |
| 비밀번호 변경 | PUT | /api/v1/members/me/password |
현재 비밀번호 검증 후 신규 비밀번호로 변경 |
3️⃣ 아키텍처 설계: 4개 계층 구조
┌─────────────────────────────────────────────────────┐
│ Interfaces Layer (API, Filter, Resolver, Config) │ ← HTTP 요청/응답, 인증, 파라미터 주입
├─────────────────────────────────────────────────────┤
│ Application Layer (Facade) │ ← 트랜잭션 경계, 도메인 서비스 조율
├─────────────────────────────────────────────────────┤
│ Domain Layer (Entity, VO, Service) │ ← 순수 POJO, 비즈니스 로직
├─────────────────────────────────────────────────────┤
│ Infrastructure Layer (Repository, Adapter) │ ← JPA, BCrypt 등 기술 구현
└─────────────────────────────────────────────────────┘
4️⃣ 계층별 상세 컴포넌트 (총 22개 메인 소스)
📌 Domain Layer (순수 POJO, 8개 파일)
| 파일 | 타입 | 책임 | 핵심 로직 |
|---|---|---|---|
Member.java |
Entity | 회원 엔티티 | ID 기반 동등성, 비밀번호 변경 메서드 |
MemberId.java |
VO | 회원 ID | 길이 4~20자, 영문/숫자/_ 검증 |
Name.java |
VO | 이름 | trim 적용, 마스킹(홍*동) |
Email.java |
VO | 이메일 | 정규식 검증, 최대 100자 |
Password.java |
VO | 비밀번호 | 정책 검증(8~20자, 영문+숫자 필수, 생년월일 포함 불가), 변경 시 동일 비번 차단 |
BirthDate.java |
VO | 생년월일 | yyyyMMdd 포맷, 미래 날짜 차단, LocalDate 저장 |
MemberService.java |
Domain Service | 회원가입/비번 변경 로직 | VO 검증, 중복 확인, 엔티티 생성 |
MemberRepository.java |
Interface | 리포지토리 포트 | 도메인 계층의 저장소 추상화 |
PasswordEncoder.java |
Interface | 암호화 포트 | 도메인 계층의 암호화 추상화 |
핵심 설계 원칙:
MemberService는@Service제거 → 순수 POJO- VO는 모두
@EqualsAndHashCode적용 → 값 기반 동등성 - 생성 시점(
of(),validate())에 모든 검증 강제 → 잘못된 상태의 객체 생성 불가
📌 Application Layer (트랜잭션 경계, 1개 파일)
| 파일 | 책임 | 의존성 |
|---|---|---|
MemberFacade.java |
@Transactional 설정, 도메인 서비스 호출 위임 |
MemberService |
설계 의도: 컨트롤러가 도메인 서비스를 직접 호출하지 않고 Facade를 통해 호출 → 트랜잭션 관리 일원화
📌 Infrastructure Layer (기술 구현, 3개 파일)
| 파일 | 책임 | 기술 스택 |
|---|---|---|
MemberJpaRepository.java |
Spring Data JPA 인터페이스 | JpaRepository |
MemberRepositoryImpl.java |
Repository 포트 구현체, 동시성 제어 | DataIntegrityViolationException → CoreException(CONFLICT) 변환 |
BCryptPasswordEncoderAdapter.java |
BCrypt 암호화 어댑터 | Spring Security BCrypt |
핵심 개선:
- Repository에서 unique constraint 위반 시 도메인 예외로 변환 → 동시 가입 제어
📌 Interfaces Layer (HTTP, 인증, 10개 파일)
API & DTO
| 파일 | 책임 |
|---|---|
MemberV1Controller.java |
3개 엔드포인트, DTO 변환, @LoginUser 파라미터 활용 |
MemberV1Dto.java |
요청/응답 DTO (SignupRequest, PasswordChangeRequest 등) |
인증 & 파라미터 주입
| 파일 | 책임 | 핵심 로직 |
|---|---|---|
AuthenticationFilter.java |
헤더 기반 인증(X-Loopers-LoginId, X-Loopers-LoginPw) |
public path 정교한 매칭(isPathMatch()), setAttribute("authenticatedMember") |
LoginUser.java |
커스텀 애너테이션 | 컨트롤러 파라미터에 @LoginUser Member member 선언 |
LoginUserArgumentResolver.java |
ArgumentResolver 구현 | request.getAttribute() → Member 타입 안전 변환, null/타입 불일치 시 UNAUTHORIZED |
설정
| 파일 | 책임 |
|---|---|
WebConfig.java |
ArgumentResolver 등록, Filter 등록 |
DomainConfig.java |
MemberService를 @Bean으로 수동 등록 |
핵심 개선:
@LoginUser도입으로 매직 스트링("authenticatedMember") 제거isPathMatch()정교한 매칭으로/signup-admin오매칭 방지
5️⃣ 테스트 커버리지 (총 9개 테스트 파일, 1,259줄)
단위 테스트 (7개)
| 파일 | 테스트 대상 | 주요 케이스 |
|---|---|---|
PasswordTest.java |
비밀번호 정책 | 길이, 영문/숫자 필수, 생년월일 포함, 변경 시 동일 비번 |
BirthDateTest.java |
생년월일 | 포맷, 미래 날짜, 윤년, cause 보존 |
EmailTest.java |
이메일 | 정규식, 길이 제한 |
MemberIdTest.java |
회원 ID | 길이, 허용 문자, equals/hashCode |
NameTest.java |
이름 | trim, 마스킹, 길이 제한 |
MemberTest.java |
Member 엔티티 | 비밀번호 변경(성공/실패 케이스: 현재 비번 불일치, 정책 위반, 동일 비번) |
MemberServiceTest.java |
MemberService | 회원가입 중복 검증, 순수 POJO 테스트 |
통합 테스트 (2개)
| 파일 | 테스트 대상 | 주요 케이스 |
|---|---|---|
MemberV1ApiE2ETest.java |
3개 API 전체 플로우 | 회원가입 → 내 정보 조회 → 비밀번호 변경 → 변경된 비번으로 재인증 |
AuthenticationFilterTest.java |
인증 필터 | public path 매칭, 인증 성공/실패, 헤더 누락 |
테스트 통계:
- 총 테스트 메서드: 50개 이상
- 성공/실패 케이스 모두 검증
- 경계값 테스트 다수 포함
6️⃣ 피드백 대응 및 개선 과정
초기 피드백 (13개 이슈)
| 번호 | 이슈 | 심각도 | 대응 완료 |
|---|---|---|---|
| 1 | 회원가입 동시성 제어 부족 | 🔴 높음 | ✅ MemberRepositoryImpl에서 처리 |
| 2 | VO equals/hashCode 누락 | 🔴 높음 | ✅ 모든 VO에 @EqualsAndHashCode 추가 |
| 3 | 헤더 기반 평문 비밀번호 전송 | 🔴 높음 | 🔜 후속 PR (JWT/세션 전환 예정) |
| 4 | BirthDate 미래 날짜 검증 누락 | 🟡 중간 | ✅ validateNotFuture() 추가 |
| 5 | Name 공백 처리 부족 | 🟡 중간 | ✅ 생성자에서 trim() 적용 |
| 6 | AuthenticationFilter path 매칭 오류 | 🟡 중간 | ✅ isPathMatch() 정교화 |
| 7 | LoginUserArgumentResolver 타입 검증 부족 | 🟡 중간 | ✅ instanceof 체크 추가 |
| 8 | 비밀번호 변경 실패 케이스 테스트 누락 | 🟡 중간 | ✅ MemberTest.UpdatePassword 추가 |
| 9 | 비밀번호 변경 후 검증 테스트 누락 | 🟡 중간 | ✅ E2E에서 재인증 검증 추가 |
| 10 | BirthDate를 String으로 저장 | 🟢 낮음 | ✅ LocalDate로 변경 |
| 11 | Password.of() 메서드명 불명확 | 🟢 낮음 | ✅ validate()로 변경 |
| 12 | 예외 처리 시 cause 미보존 | 🟢 낮음 | ✅ BirthDate에서 cause 전달 |
| 13 | BirthDate.getValue() 메서드명 혼란 | 🟢 낮음 | ✅ getFormattedValue() 추가 |
개선 커밋 이력
58431ec - Password.of() → validate() 메서드명 변경
e23dab3 - BirthDate.getValue() → getFormattedValue() 명확화
39ce405 - LocalDate 기반 저장으로 변경
a7f3b21 - 모든 VO에 equals/hashCode 구현
b9d4c12 - 비밀번호 변경 실패 케이스 테스트 추가
c5e6a34 - AuthenticationFilter path 매칭 개선
...
7️⃣ 최종 산출물 통계
파일 변경 현황
총 35개 파일 변경
- 메인 소스: 22개 (1,934줄 추가)
- 테스트: 9개 (1,259줄)
- 설정/문서: 4개 (197줄 추가, 47줄 삭제)
계층별 파일 수
Domain Layer: 9개 (Entity 1 + VO 5 + Service 1 + Interface 2)
Application Layer: 1개 (Facade)
Infrastructure Layer: 3개 (Repository 2 + Adapter 1)
Interfaces Layer: 10개 (Controller 1 + DTO 1 + Filter 1 + Resolver 2 + Config 2 + Error 2)
테스트 커버리지
단위 테스트: 7개 파일 (VO 5개 + Entity 1개 + Service 1개)
통합 테스트: 2개 파일 (E2E 1개 + Filter 1개)
총 테스트 메서드: 50개 이상
8️⃣ 핵심 아키텍처 패턴 정리
| 패턴 | 적용 위치 | 효과 |
|---|---|---|
| Value Object | Password, Email, MemberId, Name, BirthDate |
검증 로직 분산, Primitive Obsession 제거 |
| Pure Domain | MemberService (POJO) |
Spring 의존성 제거, 단위 테스트 용이 |
| Facade | MemberFacade |
트랜잭션 경계 관리, 도메인 서비스 조율 |
| Adapter | BCryptPasswordEncoderAdapter, MemberRepositoryImpl |
도메인-인프라 결합도 제거 |
| ArgumentResolver | LoginUserArgumentResolver |
매직 스트링 제거, 타입 안전성 확보 |
| Repository | MemberRepository → MemberRepositoryImpl |
도메인 계층이 인프라 기술에 의존하지 않음 |
9️⃣ 남은 후속 작업
| 작업 | 우선순위 | 이유 |
|---|---|---|
| JWT/세션 토큰 기반 인증 전환 | 🔴 높음 | 현재 헤더 평문 비밀번호 전송 방식의 보안 취약점 해결 |
| HTTPS 강제 및 헤더 로깅 차단 | 🟡 중간 | 보안 강화 (JWT 전환 전까지 임시 조치) |
| 경계값 테스트 추가 | 🟢 낮음 | 이메일 최대 길이, 특수문자, 윤년 등 엣지 케이스 보강 |
🎯 종합 평가
- ✅ TDD 사이클 준수: 테스트 50개 이상 작성, 성공/실패 케이스 모두 검증
- ✅ DDD 원칙 적용: VO 도입, Pure Domain, 책임 분산
- ✅ 유지보수성 확보: 도메인 로직이 프레임워크로부터 격리
- ✅ 타입 안전성 강화: ArgumentResolver, VO equals/hashCode
- ✅ 운영 안정성 개선: 동시성 제어, 검증 로직 강화, cause 보존
이번 PR로 회원 도메인의 견고한 기반이 완성되었으며, 향후 기능 확장 시 이 아키텍처를 템플릿으로 활용할 수 있습니다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📌 Summary
Member엔티티가 검증 로직으로 비대해지고 서비스 계층이 프레임워크에 강하게 결합되는 문제를 발견했습니다.🧭 Context & Decision
1. 비밀번호 정책 검증 위치 (Primitive Obsession 제거)
MemberService에서 검증 — 서비스가 비대해지고, 비밀번호 변경 시에도 동일한 검증 코드가 중복됨.PasswordVO 내부에서 자가 검증 (채택) — 생성 시점(Password.of())과 변경 시점(Password.change()) 모두 VO가 스스로 정책을 강제하므로 검증 누락이 불가능함.Password라는 값 자체의 불변 조건(invariant)이므로, VO가 책임지는 것이 응집도가 높다고 판단했습니다.2. 도메인 서비스 빈 등록 방식 (Pure Domain)
MemberService에서@Service를 제거하면 스프링 빈으로 등록되지 않아 의존성 주입이 불가능함.@Service유지 — 구현은 간편하지만, 도메인 계층이 Spring 프레임워크에 의존하게 됨.@Configuration+@Bean수동 등록 (채택) —DomainConfig에서 직접 생성하여 등록.3. 컨트롤러 인증 객체 주입 방식
HttpServletRequest.getAttribute("authenticatedMember")를 직접 호출하면 매직 스트링 사용과 형변환으로 인한 런타임 오류 위험이 있음.HttpServletRequest를 직접 사용 — 구현은 단순하지만, 타입 안전성이 없음.@LoginUser+ArgumentResolver도입 (채택) — 컴파일 타임에 타입이 보장되고, 컨트롤러 시그니처가 깔끔해짐.🏗️ Design Overview
변경 범위
apps/commerce-apiMember(Entity),Password,MemberId,Name,Email,BirthDate(VO),MemberService(POJO)DomainConfig,WebConfigMemberFacadeMemberV1Controller,LoginUserArgumentResolver,AuthenticationFilterMemberService의 Spring 의존성 제거주요 컴포넌트 책임
MemberV1ControllerAuthenticationFilterauthenticatedMember속성 세팅LoginUserArgumentResolverMember객체를 꺼내@LoginUser파라미터로 주입MemberFacadeMemberServicePassword(VO)Name(VO)masked())DomainConfigMemberService를@Bean으로 수동 등록🔁 Flow Diagram
Main Flow — 회원가입
sequenceDiagram autonumber participant Client participant Filter as AuthenticationFilter participant API as MemberV1Controller participant Facade as MemberFacade participant Service as MemberService participant VO as Password/MemberId(VO) participant DB as MemberRepository Client->>Filter: POST /api/v1/members/signup Note over Filter: PUBLIC_PATH → 인증 생략 Filter->>API: chain.doFilter() API->>Facade: signup(command) rect rgb(240, 248, 255) Note right of Facade: 트랜잭션 시작 Facade->>Service: signup(command) Service->>VO: new MemberId(), new BirthDate() 등 VO 생성 및 검증 Service->>DB: existsByMemberIdValue() — 중복 확인 Service->>VO: Password.of() — 비밀번호 정책 검증 Service->>VO: passwordEncoder.encode() — 암호화 Service->>DB: save(member) end DB-->>API: Member API-->>Client: 200 OK (memberId, name, email)Main Flow — 내 정보 조회
sequenceDiagram autonumber participant Client participant Filter as AuthenticationFilter participant API as MemberV1Controller participant Resolver as LoginUserArgumentResolver Client->>Filter: GET /api/v1/members/me Note over Filter: 헤더 인증 &<br/>setAttribute Filter->>API: chain.doFilter() Note over API, Resolver: 컨트롤러 진입 전<br/>ArgumentResolver 실행 API->>Resolver: resolveArgument() Resolver-->>API: Member 객체 반환 Note over API: me(@LoginUser) 실행 API-->>Client: 200 OK (마스킹된 이름)Main Flow — 비밀번호 변경
sequenceDiagram autonumber participant Client participant Filter as AuthenticationFilter participant API as MemberV1Controller participant Facade as MemberFacade participant Service as MemberService participant Domain as Member/Password(VO) participant DB as MemberRepository Client->>Filter: PUT /api/v1/members/me/password Filter->>Filter: 인증 수행 → authenticatedMember 세팅 Filter->>API: chain.doFilter() Note over API: @LoginUser로 Member 주입 API->>Facade: changePassword(member, oldPw, newPw) rect rgb(240, 248, 255) Note right of Facade: 트랜잭션 시작 Facade->>Service: changePassword() Service->>Domain: member.updatePassword() Domain->>Domain: Password.change() — 현재PW 검증, 정책 검증, 동일PW 검증 Domain-->>Service: password 필드 교체 완료 end Note right of Facade: 트랜잭션 커밋 → Dirty Checking flush Facade->>DB: 변경 감지 반영 Facade-->>API: void API-->>Client: 200 OK