Refactor: 케이크 샵 인증 요청 로직 개선

[YongsHub]

Description

주요 변경 사항

• 사장님 인증 요청 시, cakeShopId nullable 제거
• CakeShop linked_flag 제거
• 테스트 코드 리팩토링
• User Role - Business Owner 제거
• 사장님 인증 요청 시, 검증과 업데이트 로직 분리 (VerificationPolicy)
• 케이크 샵 또는 케이크 정보 수정 시, 인증(Approved) 여부와 User 정보 여부로 조건부 쿼리 업데이트

테스트 코드 주요 사항
요청 단계에 따른 테스트 코드로 검증
user role이 admin이 아닐 떄, 케이크 또는 케이크 샵 업데이트 시 조건부 쿼리 동작 여부 검증
cake_shop에서 linked_flag column이 제거됨으로써 sql 파일 수정

Core Code

etc

[github-actions]

Test Results

196 tests   196 ✅  17s ⏱️
 34 suites    0 💤
 34 files      0 ❌

Results for commit 8e9a05c.

♻️ This comment has been updated with latest results.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

@@              Coverage Diff              @@
##             develop     #189      +/-   ##
=============================================
- Coverage      89.26%   89.11%   -0.15%     
+ Complexity       329      326       -3     
=============================================
  Files            110      110              
  Lines            987      983       -4     
  Branches          37       37              
=============================================
- Hits             881      876       -5     
  Misses            88       88              
- Partials          18       19       +1     

Files	Coverage Δ	Complexity Δ
...akk/api/dto/request/user/CertificationRequest.java	100.00% <ø> (ø)	2.00 <0.00> (ø)
.../src/main/java/com/cakk/api/mapper/ShopMapper.java	92.45% <ø> (-0.21%)	23.00 <0.00> (-1.00)
...in/java/com/cakk/api/service/shop/ShopService.java	98.59% <100.00%> (-0.02%)	20.00 <1.00> (-1.00)

... and 2 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3626d1b...8e9a05c. Read the comment docs.

[lcomment]

확인했습니다.

이 부분은 어디에 적용돼 있을까요?

[YongsHub]

확인했습니다.

이 부분은 어디에 적용돼 있을까요?

"인증 정책" 이라는 객체가 requestCertificationBusinessOwner 오퍼레이션을 수행할 떄, businessInformation에게 백업하도록 요청보냅니다.

[lcomment]

확인했습니다.
이 부분은 어디에 적용돼 있을까요?

"인증 정책" 이라는 객체가 requestCertificationBusinessOwner 오퍼레이션을 수행할 떄, businessInformation에게 백업하도록 요청보냅니다.

그럼 한명이 인증 요청을 보냈을 때, 다른 사람이 인증 요청을 보내면 어떻게 되나요?

[YongsHub]

확인했습니다.
이 부분은 어디에 적용돼 있을까요?

"인증 정책" 이라는 객체가 requestCertificationBusinessOwner 오퍼레이션을 수행할 떄, businessInformation에게 백업하도록 요청보냅니다.

그럼 한명이 인증 요청을 보냈을 때, 다른 사람이 인증 요청을 보내면 어떻게 되나요?

거절됩니다! 요청 상태가 Default값인 NOT-REQUESTED -> PENDING 상태가 되기 때문에 다른 사람이 인증 요청을 보낼 수 없습니다. 기획적으로도 공동 사장을 두거나 하는 "확장성"을 승기가 제거하자고 해서 거절됩니다

[YongsHub]

확인했습니다.
이 부분은 어디에 적용돼 있을까요?

"인증 정책" 이라는 객체가 requestCertificationBusinessOwner 오퍼레이션을 수행할 떄, businessInformation에게 백업하도록 요청보냅니다.

그럼 한명이 인증 요청을 보냈을 때, 다른 사람이 인증 요청을 보내면 어떻게 되나요?

거절됩니다! 요청 상태가 Default값인 NOT-REQUESTED -> PENDING 상태가 되기 때문에 다른 사람이 인증 요청을 보낼 수 없습니다. 기획적으로도 공동 사장을 두거나 하는 "확장성"을 승기가 제거하자고 해서 거절됩니다

거절(REJECTED)시에 재요청에 대한 비즈니스 로직은 기획이랑 다시 얘기해봐야 할 것 같네요

[lcomment]

확인했습니다.
이 부분은 어디에 적용돼 있을까요?

"인증 정책" 이라는 객체가 requestCertificationBusinessOwner 오퍼레이션을 수행할 떄, businessInformation에게 백업하도록 요청보냅니다.

그럼 한명이 인증 요청을 보냈을 때, 다른 사람이 인증 요청을 보내면 어떻게 되나요?

거절됩니다! 요청 상태가 Default값인 NOT-REQUESTED -> PENDING 상태가 되기 때문에 다른 사람이 인증 요청을 보낼 수 없습니다. 기획적으로도 공동 사장을 두거나 하는 "확장성"을 승기가 제거하자고 해서 거절됩니다

엔지니어 입장에서는 다양한 케이스를 고려해야 한다고 생각하는데요, 현재는 요청에 대한 어뷰징이 가능해보입니다. 예를 들어 케이크 샵과 관련없는 사람이 요청을 보내서 진짜 케이스 샵 관계자의 요청은 거절되는 케이스가 있을 수 있습니다. 사실 그래서 요청에 대한 정보를 따로 저장하려 했습니다. 우선순위가 있는 작업은 아니니 일단 냅두죠~