✨ 리팩토링 할 부분
상위 roadmap: docs/ddd-test-refactoring-roadmap.md 4.3 User Account 컨텍스트
User Account 바운디드 컨텍스트를 DDD 관점으로 점진적으로 재정리한다.
이번 작업에서는 User aggregate의 책임을 선명하게 만들고,
관심사 불변식과 User Account / Personalization Profile / Auth shared layer 경계를
후속 작업 가능한 형태로 정리한다.
🏷️ 도메인 (해당하는 것에 체크)
📌 현재 코드의 문제점
User aggregate 규칙은 서비스 테스트로는 어느 정도 보호되지만 aggregate 자체를 직접 보호하는 테스트가 약하다.
- 관심사 불변식("키워드는 선택된 카테고리에 속해야 한다") 검증이
InterestCommandService 레이어에 산재해 있다.
UserCommandService / InterestCommandService가 User Account 책임과 PersonalizationProfileService 트리거를 함께 쥐고 있어 경계가 흐리다.
global/security의 UserAuthCacheService, UserPrincipal 같은 shared layer와도 맞물려 있어, User Account 정리 시 어디까지가 도메인 책임인지 기준이 더 필요하다.
🎯 리팩토링 방향
User aggregate 핵심 규칙을 테스트로 먼저 고정한다.
- 패키지를 최상위로 승격하고
presentation / application / domain / infrastructure 레이어 기준으로 재배치한다.
- 관심사 저장/교체 규칙을 aggregate 내부 불변식으로 이동한다.
- User Account와 Personalization Profile의 책임/트리거 경계를 문서와 서비스 책임 기준으로 분리한다.
global/security는 별도 독립 컨텍스트로 분리하지 않고, User Account가 기대는 shared layer seam으로만 정리한다.
- 이벤트(
OnboardingCompleted, UserInterestsChanged) 도입은 후속 이슈로 남긴다.
✅ 작업 체크리스트
💡 기대 효과
✨ 리팩토링 할 부분
상위 roadmap:
docs/ddd-test-refactoring-roadmap.md4.3 User Account 컨텍스트User Account 바운디드 컨텍스트를 DDD 관점으로 점진적으로 재정리한다.
이번 작업에서는
Useraggregate의 책임을 선명하게 만들고,관심사 불변식과 User Account / Personalization Profile / Auth shared layer 경계를
후속 작업 가능한 형태로 정리한다.
🏷️ 도메인 (해당하는 것에 체크)
📌 현재 코드의 문제점
Useraggregate 규칙은 서비스 테스트로는 어느 정도 보호되지만 aggregate 자체를 직접 보호하는 테스트가 약하다.InterestCommandService레이어에 산재해 있다.UserCommandService/InterestCommandService가 User Account 책임과PersonalizationProfileService트리거를 함께 쥐고 있어 경계가 흐리다.global/security의UserAuthCacheService,UserPrincipal같은 shared layer와도 맞물려 있어, User Account 정리 시 어디까지가 도메인 책임인지 기준이 더 필요하다.🎯 리팩토링 방향
Useraggregate 핵심 규칙을 테스트로 먼저 고정한다.presentation / application / domain / infrastructure레이어 기준으로 재배치한다.global/security는 별도 독립 컨텍스트로 분리하지 않고, User Account가 기대는 shared layer seam으로만 정리한다.OnboardingCompleted,UserInterestsChanged) 도입은 후속 이슈로 남긴다.✅ 작업 체크리스트
💡 기대 효과