Refactor: 생성 로직 보상트랜잭션 도입 및 서비스 분리

[lunarbae628]

🛰️ Issue Number

• Refactor: 이종 DB 생성 정합성 고도화 (보상 트랜잭션 도입) #176
• Fix: 이어서 작업하기 시 브랜치 생성 실패 #183

🪐 작업 내용

변경 내용

생성 로직에 보상트랜잭션 도입

Doc의 예

[DocService]
    │
    ▼
[DocCreateOrchestrator]  ── (1) SaveContent 저장 (Mongo)
    │
    ▼
[DocCreateMySqlTxService] ── (2) Doc/Branch/Save 저장 (MySQL)
    │
    ├─ 성공 → 응답 반환
    │
    └─ 실패 → [MongoDeleteRetryService] (3) 보상 삭제 (Mongo, Retry/Recover)

Command / Query 책임 분리

• Repository에 접근하는 메소드를 QueryService로 분리 -> 추후 ValidationService 추가분리 검토 중
• Service에서 타 도메인의 Repository 직접 접근 제거(Doc/Branch/Commit/Save/Edge)

이어서 작업하기 버그 수정

• 이름 중복 처리
  새 브랜치 생성 시점에 이름 중복이 DB까지 가서 DataIntegrityViolationException로 터질 수 있었음.
  createNewBranch == true 경로에서 먼저 checkDuplicatedWithBranchName 수행해서 BRANCH_NAME_DUPLICATED로 처리.
• leaf 커밋에서의 분기
  기존로직은 isLeaf == true면 요청 이름과 무관하게 기존 브랜치 save 생성 경로로 감 -> save있는데 save또 생성하려해서 saves.branch_id 유니크 제약 위반(500) 발생

        if (isLeaf) {
            Save save = createSave(fromBranch, fromCommit.getCommitMongoId()

(펑)

(펑)

(안터져용~)

createNewBranch = !isLeaf || !sameName || (isLeaf && isRoot && hasSave)로 분기.
변경 초기에는 (isLeaf && isRoot && hasSave)는 없었으나 Leaf이면서 Root이면서 Save가 있으면서 이름이 같으면 createNewBranch가 false가 되어 이름중복 예외가 터지지않고 DataIntegrityViolationException가 또 터져서 조건을 늘렸습니다.(너무 복잡 간략화 필요)

• fromCommit ManyToOne으로 변경

이런 게 가능한 게 자연스러운 것 같아서 바꿔 봤는데 아직 문제를 찾진 못했습니다. DB 마이그레이션 예정

그 외

• 프로파일별 CORS 허용 도메인 분리
• MongoDeleteRetryService 벌크 삭제 방식으로 개선
• 의미가 애매한 메소드명 클래스명 변수명 변경
• 책임 도메인으로 메소드 이동
• BranchCreateRequest.fromCommitId에 @NotNull 적용

테스트

1. 신규 테스트 추가

• BranchCreateOrSaveIntegrationTest
  • leaf=root+save 존재+같은 이름 요청 시 BRANCH_NAME_DUPLICATED
  • leaf=root+save 존재+다른 이름 요청 시 새 branch/save 생성
  • leaf=root+save 없음+같은 이름 요청 시 기존 branch에 save 생성
  • 새 브랜치 생성 경로에서 이름 중복 시 BRANCH_NAME_DUPLICATED
• CommitCreateOrchestratorTest
  • Mongo 성공 + MySQL 성공 시 보상 삭제 미호출
  • Mongo 성공 + MySQL 실패 시 보상 삭제 호출 및 예외 전파
• DocCreateOrchestratorTest
  • Mongo 성공 + MySQL 성공 시 보상 삭제 미호출
  • Mongo 성공 + MySQL 실패 시 보상 삭제 호출 및 예외 전파

2. 기존 테스트 보강/수정

• BranchServiceTest
  • 이어서 작업 분기(이름 중복/새 브랜치 생성 경로) 단위 검증 강화
• CommitServiceMockTest
  • createCommit 경로를 Orchestrator 기반으로 재검증
  • base commit 선택(leaf/from/null) 분기 검증
  • merge 검증(동일 브랜치 요청, 권한 검증 실패) 케이스 추가
• CreateCommitIntegrationTest
  • 중복 요청 시 커밋 2건 생성(멱등키 미적용 현상) 검증
  • invalid blockOrders 실패 검증
  • MySQL 실패 시 Mongo 보상 삭제 검증
  • MySQL 실패 + 보상 삭제 실패(3회) 경로 검증
• DocServiceIntegrationTests
  • MySQL 실패 시 SaveContent 보상 삭제 검증
  • MySQL 실패 + 보상 삭제 3회 실패 시 MongoDeleteFailure 저장 검증
• DocServiceUnitTests
  • CQRS 분리 반영(조회/중복검사 위임) 검증
  • 제목 중복 시 Orchestrator 미호출 검증
• DeleteCommitIntegrationTest
  • 하드코딩 기대값을 delta(count 전후 비교) 검증으로 보강
• GetCommitMockTest / DocControllerUnitTests / DocGraphIntegrationTest / DocTestUtils
  • QueryService 분리 및 DTO/메서드명 변경 반영
• MongoDeleteRetryServiceTest
  • 테스트 간 데이터 오염 방지 cleanup(@AfterEach) 추가
• application-test.yml
  • test 프로필 CORS 설정 항목 추가

참고사항

• Service와 QueryService(repository로 직접 전근하는 레이어)로 분리하는 과정 및 충동적 수정으로 인해 코드의 변경사항이 너무 많아졌습니다.
• 프론트에서 백엔드에서 내려주는 예외 메시지가 아닌 다른 메시지를 출력하는게 늘 짜증났는데 이번기회에 수정했습니다. 프론트 수정사항은 https://github.com/lunarbae628/Docsa_FE/tree/staging 여기서 확인가능합니다.
• https://staging.docsa-4hh.pages.dev/ 에서 staging 테스트를 할 수 있습니다.

📚 Reference

• 코드의 변경사항이 많아질 것으로 예상되기에 pr을 선제적으로 게시하여 진행사항 공유드리도록 하겠습니다.
• 주기적으로 변경사항을 staging브랜치에 머지해가며 진행하겠습니다.

✅ Check List

• 코드가 정상적으로 컴파일되나요?
• 테스트 코드를 통과했나요?
• merge할 브랜치의 위치를 확인했나요?
• Label을 지정했나요?

[sleepyhoon]

안녕하세요 문성님, 리뷰는 진행이 모두 끝나고 하면 될까요?

[lunarbae628]

안녕하세요 문성님, 리뷰는 진행이 모두 끝나고 하면 될까요?

전체 작업이 끝난 뒤에 한 번에 PR을 올리면 변경 범위가 커져서 파악이 어려울 것 같아, 미리 올려두었습니다.

리뷰는 편하실 때 언제든지 진행해주셔도 괜찮습니다!

[sleepyhoon]

고생하셨습니다