[BE] feat: 의존성을 정리한다(#643) #644

BGuga · 2023-12-31T13:39:06Z

📌 관련 이슈

closed: [BE] 의존성을 정리한다. #643

✨ PR 세부 내용

의존성 정리를 진행하였고,
AuthController 에서 evnet 를 발행하고 있는데 이는 AuthServier 에 fcm 을 모르도록 만들기 위함입니다.
추후에 fcm 분리하면 생성 시점에는 해결될 것이고 삭제에는 마찬가지로 event 를 발행해야할 것 같습니다.

github-actions · 2023-12-31T13:40:39Z

Test Results

92 files 92 suites 7s ⏱️
336 tests 336 ✅ 0 💤 0 ❌
350 runs 350 ✅ 0 💤 0 ❌

Results for commit 2796e7c.

♻️ This comment has been updated with latest results.

seokjin8678

고생하셨습니다 푸우!
몇 가지 리뷰 남겼습니다.
조회가 목적인 Query 서비스와 비즈니스 로직이 담긴 명령이 목적인 Command 서비스(이름이 Command가 아니더라도)를 분리하면 좋겠네요.

지금 PR의 목적은 의존성의 정리이니, 엔티티의 변경이 생기는 부분은 추후 새로운 이슈를 만들어 해결하면 좋을 것 같습니다!
(MemberTicket의 Ticket 의존성 추가, Stage 의존성 제거)

seokjin8678 · 2024-01-01T09:27:29Z

backend/src/main/java/com/festago/fcm/application/MemberRegisterEventListener.java

+    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
+    @Async
+    @Transactional
+    public void deleteMember(DeleteMemberEvent event) {
+        memberFCMRepository.deleteAllByMemberId(event.memberId());
+    }


MemberRegisterEventListner 클래스의 역할과 달라보여서, 해당 이벤트 핸들러만 구현하는 새로운 클래스를 만드는 건 어떤가요?

좋습니다 반영했어요!!

seokjin8678 · 2024-01-01T09:57:41Z

backend/src/main/java/com/festago/fcm/application/MemberRegisterEventListener.java

+    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
+    @Async
+    @Transactional
+    public void registerNewMember(MemberRegisterEvent event) {
+        if (event.isNew()) {
+            saveNewMemberFCM(event.accessToken(), event.fcmToken());
+            return;
+        }
+        saveOriginMemberFCM(event.accessToken(), event.fcmToken());
+    }
+
+    private void saveNewMemberFCM(String accessToken, String fcmToken) {
+        Long memberId = extractMemberId(accessToken);
+        memberFCMRepository.save(new MemberFCM(memberId, fcmToken));
+    }
+
+    private Long extractMemberId(String accessToken) {
+        AuthPayload authPayload = authExtractor.extract(accessToken);
+        return authPayload.getMemberId();
+    }
+
+    private void saveOriginMemberFCM(String accessToken, String fcmToken) {
+        Long memberId = extractMemberId(accessToken);
+        Optional<MemberFCM> memberFCM = memberFCMRepository.findMemberFCMByMemberIdAndFcmToken(memberId, fcmToken);
+        if (memberFCM.isEmpty()) {
+            memberFCMRepository.save(new MemberFCM(memberId, fcmToken));
+        }
+    }


추후 #579 이슈가 처리된다면 해당 코드는 크게 바뀔 가능성이 높지만..
해당 로직을 단순화하면 다음과 같이 리팩터링 할 수 있을 것 같네요.

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) @Async @Transactional public void registerNewMember(MemberRegisterEvent event) { Long memberId = extractMemberId(event.accessToken()); String fcmToken = event.fcmToken(); memberFCMRepository.findByMemberIdAndFcmToken(memberId, fcmToken) .orElseGet(() -> memberFCMRepository.save(new MemberFCM(memberId, fcmToken))); } private Long extractMemberId(String accessToken) { AuthPayload authPayload = authExtractor.extract(accessToken); return authPayload.getMemberId(); }

여기서 봐야할 건 MemberRegisterEvent가 isNew 라는 필드를 가져야하나 싶어요.
메타데이터로 사용된다면 isNew가 true일 때 SELECT 쿼리를 날리지 않고, 바로 save를 하여 성능을 조금 챙길 수 있다는 장점이 있겠네요.

isNew 필드를 생략한다면 AuthController의 로직 또한 다음과 같이 변경이 가능해요.

@PostMapping("/oauth2") @Operation(description = "소셜 엑세스 토큰을 기반으로 로그인 요청을 보낸다.", summary = "OAuth2 로그인") public ResponseEntity<LoginResponse> login(@RequestBody @Valid LoginRequest request) { LoginResponse response = authFacadeService.login(request.socialType(), request.accessToken()); publisher.publishEvent(new MemberRegisterEvent(request.accessToken(), request.fcmToken())); return ResponseEntity.ok() .body(response); }

원래는 조회 쿼리 한 번을 줄이자는 생각이었는데 큰 연산이 아니란 생각이드네요!
작성 당시에는 어차피 새로운 멤버 여부를 알 수 있는 데이터가 있으니 주어진 데이터를 활용해서 최적화해보자 라는 생각이었지만
오히려 복잡해보이는 부분이 더 큰 단점으로 다가오네요 반영했습니다!

@PostMapping("/oauth2") @Operation(description = "소셜 엑세스 토큰을 기반으로 로그인 요청을 보낸다.", summary = "OAuth2 로그인") public ResponseEntity<LoginResponse> login(@RequestBody @Valid LoginRequest request) { LoginResponse response = authFacadeService.login(request.socialType(), request.accessToken()); publisher.publishEvent(new MemberRegisterEvent(request.accessToken(), request.fcmToken())); return ResponseEntity.ok() .body(response); }

여기서

new MemberRegisterEvent(response.accessToken(), request.fcmToken());

request -> response 오타 수정해서 반영했어요

seokjin8678 · 2024-01-01T09:59:33Z

backend/src/main/java/com/festago/fcm/application/MemberRegisterEventListener.java

+
+    private void saveOriginMemberFCM(String accessToken, String fcmToken) {
+        Long memberId = extractMemberId(accessToken);
+        Optional<MemberFCM> memberFCM = memberFCMRepository.findMemberFCMByMemberIdAndFcmToken(memberId, fcmToken);


memberFCMRepository 의 findMemberFCMByMemberIdAndFcmToken() 메서드 명을 findByMemberIdAndFcmToken()로 줄일 수 있겠네요.

seokjin8678 · 2024-01-01T10:00:39Z

backend/src/main/java/com/festago/festival/application/FestivalStageService.java

+import com.festago.festival.dto.DetailFestivalResponse;
+import org.springframework.stereotype.Component;
+
+@Component


인터페이스에 붙은 @Component는 지워도 좋을 것 같아요!

seokjin8678 · 2024-01-01T10:29:46Z

backend/src/main/java/com/festago/festival/application/FestivalStageService.java

+public interface FestivalStageService {
+
+    DetailFestivalResponse findDetail(Long festivalId);
+}


해당 인터페이스가 필요한 이유가 Festival이 Stage에 대한 의존이 없어야 하지만, 조회 기능 때문에 반드시 Stage에 대한 의존이 필요하니 해당 의존성을 분리하려고 만든 특수한 목적의 인터페이스라고 이해했습니다!

하지만 단순히 이름만 보았을 때 해당 인터페이스가 조회만 하는 특수한 목적의 인터페이스라고 알기 힘드니, FestivalStageQueryService 같이 명확한 이름을 부여해주는 것은 어떤가요?

이 부분은 결국 모든 조회 로직마다 의존성을 없애는게 어렵다라는 이야기를 회의 때 했던 것처럼
(이론적으로 가능은 한데, 하나 하나 인터페이스가 생겨야한다.)

조회는 별도의 QueryService로 하고, QueryService에서만 양방향 의존성을 감수하는게 좋을 것 같다는 생각이 드네요.
즉, 변경이 여러 지점에 있지만, 그 클래스는 최소화 하는 형태로?

명확하게 할려면 application/query 이런식으로 패키지를 한번 더 나눌 수도 있을 거같은데, 어차피 application에 존재하는 serivce가 몇개 없을거라 패키지를 안나눠도 괜찮다는 생각은 듭니다.

쿼리 서비스 분리는 작업 단위가 커지는 것 같아 별도의 Issue로 처리할게요!

seokjin8678 · 2024-01-01T11:01:14Z

backend/src/main/java/com/festago/stage/application/FestivalStageServiceImpl.java

+            .orElseThrow(() -> new NotFoundException(ErrorCode.FESTIVAL_NOT_FOUND));
+    }
+
+    private DetailStageResponse makeResponse(Stage stage) {


make라는 이름보다는 create는 어떤가요?

seokjin8678 · 2024-01-01T11:04:14Z

backend/src/main/java/com/festago/stage/application/FestivalStageServiceImpl.java

+    private Function<Ticket, DetailTicketResponse> makeTicketResponse() {
+        return ticket -> {
+            TicketAmount ticketAmount = ticket.getTicketAmount();
+            return new DetailTicketResponse(
+                ticket.getId(),
+                ticket.getTicketType().name(),
+                ticketAmount.getTotalAmount(),
+                ticketAmount.calculateRemainAmount()
+            );
+        };
+    }


return 타입을 DetailTicketResponse로 반환하는건 어떤가요?

private DetailTicketResponse createDetailTicketResponse(Ticket ticket) { TicketAmount ticketAmount = ticket.getTicketAmount(); return new DetailTicketResponse( ticket.getId(), ticket.getTicketType().name(), ticketAmount.getTotalAmount(), ticketAmount.calculateRemainAmount() ); }

seokjin8678 · 2024-01-01T11:15:06Z

backend/src/main/java/com/festago/ticket/domain/ReservationSequence.java

+public class ReservationSequence {
+
+    private static final int MOST_FAST_SEQUENCE = 1;
+    private final int value;
+
+    public ReservationSequence(int value) {
+        validate(value);
+        this.value = value;
+    }
+
+    private void validate(int sequence) {
+        if (sequence < MOST_FAST_SEQUENCE) {
+            throw new InternalServerException(ErrorCode.TICKET_SEQUENCE_DATA_ERROR);
+        }
+    }
+
+    public int getValue() {
+        return value;
+    }
+}


해당 값 타입 객체를 만들어 사용해주신 이유가 있을까요?

reservation 이란 값을 Service 에서 MemberTicket -> Ticket 의 메서드까지 타고가면서 잘못된 값이 들어갔을 때 검증이 너무 늦게 발생한다는 문제가 발생해서 값 객체로 선언했습니다!

seokjin8678 · 2024-01-01T11:19:46Z

backend/src/main/java/com/festago/ticket/domain/TicketInfo.java

+public class TicketInfo {
+
+    private final Stage stage;
+    private final ReservationSequence sequence;
+    private final LocalDateTime entryTime;
+    private final TicketType ticketType;
+
+    public TicketInfo(Stage stage, ReservationSequence sequence, LocalDateTime entryTime,
+                      TicketType ticketType) {
+        validate(stage, sequence, entryTime, ticketType);
+        this.stage = stage;
+        this.sequence = sequence;
+        this.entryTime = entryTime;
+        this.ticketType = ticketType;
+    }
+
+    private void validate(Stage stage, ReservationSequence sequence, LocalDateTime entryTime, TicketType ticketType) {
+        validateStage(stage);
+        validateSequence(sequence);
+        validateEntryTime(entryTime);
+        validateTicketType(ticketType);
+    }
+
+    private void validateStage(Stage stage) {
+        Validator.notNull(stage, "stage");
+    }
+
+    private void validateSequence(ReservationSequence sequence) {
+        Validator.notNull(sequence, "sequence");
+    }
+
+    private void validateEntryTime(LocalDateTime entryTime) {
+        Validator.notNull(entryTime, "entryTime");
+    }
+
+    private void validateTicketType(TicketType ticketType) {
+        Validator.notNull(ticketType, "ticketType");
+    }
+
+    public Stage getStage() {
+        return stage;
+    }
+
+    public ReservationSequence getSequence() {
+        return sequence;
+    }
+
+    public LocalDateTime getEntryTime() {
+        return entryTime;
+    }
+
+    public TicketType getTicketType() {
+        return ticketType;
+    }
+}


해당 클래스는 DTO 용도의 클래스로 보이는데 record로 변환한다면 다음과 같이 변경할 수 있습니다!
compact construtor를 사용하여 코드를 최소화 할 수 있습니다.
자세한 내용은 링크 참조하시면 좋을 것 같네요.

public record TicketInfo( Stage stage, ReservationSequence sequence, LocalDateTime entryTime, TicketType ticketType ) { public TicketInfo { validate(stage, sequence, entryTime, ticketType); } private void validate(Stage stage, ReservationSequence sequence, LocalDateTime entryTime, TicketType ticketType) { validateStage(stage); validateSequence(sequence); validateEntryTime(entryTime); validateTicketType(ticketType); } private void validateStage(Stage stage) { Validator.notNull(stage, "stage"); } private void validateSequence(ReservationSequence sequence) { Validator.notNull(sequence, "sequence"); } private void validateEntryTime(LocalDateTime entryTime) { Validator.notNull(entryTime, "entryTime"); } private void validateTicketType(TicketType ticketType) { Validator.notNull(ticketType, "ticketType"); } }

또한 이름을 TicketInfo 보단, 예매를 위한 정보를 전송하므로 TicketReserveInfo와 같이 명확하게 변경해도 좋을 것 같네요.

record 를 안 썼던 이유가 해당 객체를 domain 간에 주고 받기 때문에 값 객체라 생각하였었습니다.
record 로 선언해도 좋을 것 같네요!

seokjin8678 · 2024-01-01T11:56:56Z

backend/src/main/java/com/festago/ticketing/domain/MemberTicket.java

+    public static MemberTicket createMemberTicket(Ticket ticket, Member member, ReservationSequence sequence,
+                                                  LocalDateTime currentTime) {
+        if (ticket.alreadyStart(currentTime)) {
+            throw new BadRequestException(ErrorCode.TICKET_CANNOT_RESERVE_STAGE_START);
+        }
+
+        TicketInfo ticketInfo = extractTicketInfo(ticket, sequence);
+        return new MemberTicket(
+            member,
+            ticketInfo.getStage(),
+            ticketInfo.getSequence().getValue(),
+            ticketInfo.getEntryTime(),
+            ticketInfo.getTicketType()
+        );
+    }
+
+    private static TicketInfo extractTicketInfo(Ticket ticket, ReservationSequence sequence) {
+        return ticket.extractTicketInfo(sequence);
+    }


해당 메서드가 필요한 이유는 MemberTicket을 생성할 때 Ticket의 Stage가 시작되었는지 확인하기 위해서 같네요.
MemberTicket의 생성자로 Stage가 아닌 Ticket을 받는게 더 적절하지 않나 싶어요.
왜냐하면 MemberTicket가 참조하는 Stage는 단순히 조회에서 사용되더군요. (그것도 식별자만)
그렇게 한다면 TicketInfo라는 DTO는 사용하지 않아도 될 것 같네요.

저는 굳이 이제 이 로직이 static factory method일 필요가 있나 싶어요.
Ticket이 아니라 Stage가 필요한거라 TicketInfo를 받거나 아니면 getter로 하나씩 꺼내줘서 생성자로 만들어주는게 좋다는 생각이 드네요.

해당 메서드가 필요한 이유는 MemberTicket을 생성할 때 Ticket의 Stage가 시작되었는지 확인하기 위해서 같네요.
MemberTicket의 생성자로 Stage가 아닌 Ticket을 받는게 더 적절하지 않나 싶어요.
왜냐하면 MemberTicket가 참조하는 Stage는 단순히 조회에서 사용되더군요. (그것도 식별자만)
그렇게 한다면 TicketInfo라는 DTO는 사용하지 않아도 될 것 같네요.

맞아요.. 그래서 저희 MemberTicket 에 Ticket 참조를 갖도록 변경하는 작업을 진행하는 것이 좋을까요??

저는 굳이 이제 이 로직이 static factory method일 필요가 있나 싶어요.
Ticket이 아니라 Stage가 필요한거라 TicketInfo를 받거나 아니면 getter로 하나씩 꺼내줘서 생성자로 만들어주는게 좋다는 생각이 드네요.

Service 에서 MemberTicket을 만드는 것을 생각하신 건가요??

MemberTicket의 생성자로 만들되 필요한 인자를 꺼내서 넣어주는 걸 생각했었어요!

carsago

간단한 코멘트를 남겨보았습니다.

carsago · 2024-01-04T04:22:44Z

backend/src/main/java/com/festago/ticketing/domain/MemberTicket.java

+    public static MemberTicket createMemberTicket(Ticket ticket, Member member, ReservationSequence sequence,
+                                                  LocalDateTime currentTime) {
+        if (ticket.alreadyStart(currentTime)) {
+            throw new BadRequestException(ErrorCode.TICKET_CANNOT_RESERVE_STAGE_START);
+        }
+
+        TicketInfo ticketInfo = extractTicketInfo(ticket, sequence);
+        return new MemberTicket(
+            member,
+            ticketInfo.getStage(),
+            ticketInfo.getSequence().getValue(),
+            ticketInfo.getEntryTime(),
+            ticketInfo.getTicketType()
+        );
+    }
+
+    private static TicketInfo extractTicketInfo(Ticket ticket, ReservationSequence sequence) {
+        return ticket.extractTicketInfo(sequence);
+    }


저는 굳이 이제 이 로직이 static factory method일 필요가 있나 싶어요.
Ticket이 아니라 Stage가 필요한거라 TicketInfo를 받거나 아니면 getter로 하나씩 꺼내줘서 생성자로 만들어주는게 좋다는 생각이 드네요.

carsago · 2024-01-04T04:25:43Z

backend/src/main/java/com/festago/festival/application/FestivalStageService.java

+public interface FestivalStageService {
+
+    DetailFestivalResponse findDetail(Long festivalId);
+}


이 부분은 결국 모든 조회 로직마다 의존성을 없애는게 어렵다라는 이야기를 회의 때 했던 것처럼
(이론적으로 가능은 한데, 하나 하나 인터페이스가 생겨야한다.)

조회는 별도의 QueryService로 하고, QueryService에서만 양방향 의존성을 감수하는게 좋을 것 같다는 생각이 드네요.
즉, 변경이 여러 지점에 있지만, 그 클래스는 최소화 하는 형태로?

명확하게 할려면 application/query 이런식으로 패키지를 한번 더 나눌 수도 있을 거같은데, 어차피 application에 존재하는 serivce가 몇개 없을거라 패키지를 안나눠도 괜찮다는 생각은 듭니다.

carsago · 2024-01-04T04:27:50Z

backend/src/main/java/com/festago/auth/presentation/AuthController.java

@@ -24,7 +26,7 @@
 public class AuthController {

    private final AuthFacadeService authFacadeService;
-    private final MemberFCMService memberFCMService;
+    private final ApplicationEventPublisher publisher;


ApplicationEventPublisher가 AuthFacadeService 내부에서 이벤트를 발행해주는 건 어떨까요?

동의합니다! 이벤트 발행은 서비스 내부에서 하는게 통일성있을 것 같아요!

그러면 Auth Service 가 fcm 을 알게되는데 괜찮을까용??

신경 쓰이긴한데, 사실 Controller에서 알기 때문에 패키지 의존성은 상관 없지않을까요..?

carsago · 2024-01-04T06:13:30Z

backend/src/main/java/com/festago/stage/application/FestivalStageServiceImpl.java

+    public DetailFestivalResponse findDetail(Long festivalId) {
+        Festival festival = findFestival(festivalId);
+        return stageRepository.findAllDetailByFestivalId(festivalId).stream()
+            .sorted(comparing(Stage::getStartTime))
+            .map(this::makeResponse)
+            .collect(collectingAndThen(
+                toList(),
+                stageResponses -> new DetailFestivalResponse(
+                    festivalId,
+                    festival.getSchool().getId(),
+                    festival.getName(),
+                    festival.getStartDate(),
+                    festival.getEndDate(),
+                    festival.getThumbnail(),
+                    stageResponses
+                )
+            ));
+    }


이 부분을 Festival이랑 List를 DetailFestivalResponse 생성자로 받아서 처리하는 것도 괜찮겠네요.

DetailFestivalResposne, DetailStageResponse, DetailTicketResponse는 양방향 참조를 피하기 위해 festival 패키지에 모두 같이 있어야합니다!!
그래서 해당 Dto 에 Stage, Ticket이 넘어올 경우 festival <-> Stage, Ticket 에 대한 의존성이 생기기 때문에 이렇게 Service 에서 직접 만들어주었습니다!

xxeol2

글렌과 오리가 자세하게 코멘트 남겨주셨네요 😁
간단한 코멘트 남기고 갑니다!!

xxeol2 · 2024-01-04T07:58:23Z

backend/src/main/java/com/festago/auth/dto/event/DeleteMemberEvent.java

+public record DeleteMemberEvent(
+    Long memberId
+) {
+
+}


Event 이름이 얘는 DeleteMemberEvent 이고 다른 이벤트는 MemberRegisterEvent인데 통일하면 좋을 것 같아요!

xxeol2 · 2024-01-04T07:59:16Z

backend/src/main/java/com/festago/auth/presentation/AuthController.java

@@ -24,7 +26,7 @@
 public class AuthController {

    private final AuthFacadeService authFacadeService;
-    private final MemberFCMService memberFCMService;
+    private final ApplicationEventPublisher publisher;


동의합니다! 이벤트 발행은 서비스 내부에서 하는게 통일성있을 것 같아요!

xxeol2 · 2024-01-04T08:05:52Z

backend/src/main/java/com/festago/festival/dto/DetailFestivalResponse.java

+public record DetailFestivalResponse(
+    Long id,
+    Long schoolId,
+    String name,
+    LocalDate startDate,
+    LocalDate endDate,
+    String thumbnail,
+    List<DetailStageResponse> stages) {
+
+}


나중에 보면 헷갈릴 수 있다는 글렌의 말씀에 동의합니다!
다만 글렌이 제시해주신 방법처럼 한다면 외부에서 StageResponse를 사용할 때, 실제 StageResponse.java 클래스의 응답객체와 DeatilFestivalResponse 내부 StageResponse 둘 다 노출되어 헷갈릴수도 있겠네요..

xxeol2 · 2024-01-04T08:12:28Z

backend/src/main/java/com/festago/stage/application/FestivalStageServiceImpl.java

+@Service
+@Transactional
+@RequiredArgsConstructor
+public class FestivalStageServiceImpl implements FestivalStageService {
+
+    private final StageRepository stageRepository;
+    private final FestivalRepository festivalRepository;
+


이 서비스를 보니까, 조회와 명령 서비스를 분리하는 이유가 더 잘 보이긴하네요..
다른 비즈니스로직을 수행하는 메서드와 얘가 섞여있었다면 비즈니스로직이 눈에 보이지 않을 것 같네요

xxeol2 · 2024-01-04T08:13:06Z

backend/src/main/java/com/festago/ticket/domain/ReservationSequence.java

+    private static final int MOST_FAST_SEQUENCE = 1;
+    private final int value;


상수와 변수 사이 한 칸 공백 넣어주는건 어떨까용

xxeol2 · 2024-01-04T08:14:10Z

backend/src/test/java/com/festago/acceptance/EntryPoint.java

-public class EntryPoint {
-
-}
+// TODO: Cucumber 어쩔티비냐


seokjin8678

리뷰 반영 모두 확인했습니다!
고생하셨습니다!

carsago

고생하셨습니다 푸우
코멘트 달아주신 거 덕분에 구현 방식에 관한 부분이 대부분 공감됐습니다.

carsago · 2024-01-08T09:50:36Z

backend/src/main/java/com/festago/auth/presentation/AuthController.java

@@ -24,7 +26,7 @@
 public class AuthController {

    private final AuthFacadeService authFacadeService;
-    private final MemberFCMService memberFCMService;
+    private final ApplicationEventPublisher publisher;


신경 쓰이긴한데, 사실 Controller에서 알기 때문에 패키지 의존성은 상관 없지않을까요..?

carsago · 2024-01-08T09:51:38Z

backend/src/main/java/com/festago/ticketing/domain/MemberTicket.java

+    public static MemberTicket createMemberTicket(Ticket ticket, Member member, ReservationSequence sequence,
+                                                  LocalDateTime currentTime) {
+        if (ticket.alreadyStart(currentTime)) {
+            throw new BadRequestException(ErrorCode.TICKET_CANNOT_RESERVE_STAGE_START);
+        }
+
+        TicketInfo ticketInfo = extractTicketInfo(ticket, sequence);
+        return new MemberTicket(
+            member,
+            ticketInfo.getStage(),
+            ticketInfo.getSequence().getValue(),
+            ticketInfo.getEntryTime(),
+            ticketInfo.getTicketType()
+        );
+    }
+
+    private static TicketInfo extractTicketInfo(Ticket ticket, ReservationSequence sequence) {
+        return ticket.extractTicketInfo(sequence);
+    }


MemberTicket의 생성자로 만들되 필요한 인자를 꺼내서 넣어주는 걸 생각했었어요!

BGuga added 11 commits December 31, 2023 21:14

refactor: presentation 을 각 컨텍스트에 배치한다

d2fdda7

refactor: auth 가 fcm 에 의존하지 않도록 event 로 처리한다

bbbdac3

refactor: memberTicket <-> entry 양방향 의존을 제거하기 위해 입장 코드 생성을 entry 로 위임한다.

f00ed81

refactor: Ticket 이 MemberTicket 을 모르도록 변경

723cf57

refactor: admin 이 auth 에 대한 의존성이 없도록 변경

be200ab

refactor: festival 이 stage 를 모르도록 변경

b64ac21

refactor: festival 이 stage 나 ticket 을 모르도록 변경

0257386

refactor: fcm listener 비동기로 작동하도록 변경

6a9b7a5

refactor: TicketInfo 리팩터링

7fe0844

test: 기존 테스트 코드를 위치에 맞게 재배분

29853fc

test: 깨지는 테스트 수정

fa24701

BGuga linked an issue Dec 31, 2023 that may be closed by this pull request

[BE] 의존성을 정리한다. #643

Closed

BGuga self-assigned this Dec 31, 2023

seokjin8678 requested changes Jan 1, 2024

View reviewed changes

seokjin8678 requested review from xxeol2 and carsago January 2, 2024 08:55

seokjin8678 added ⚙️ 리팩터링 리팩터링에 관련된 작업 BE 백엔드에 관련된 작업 labels Jan 2, 2024

carsago reviewed Jan 4, 2024

View reviewed changes

xxeol2 reviewed Jan 4, 2024

View reviewed changes

BGuga added 9 commits January 6, 2024 23:32

refactor: 멤버 삭제시 fcm 삭제를 DeletionEventListener 가 처리한다.

53025fb

refactor: 로그인 시 발행하는 Event 에 새로운 멤버 여부를 포함시키지 않도록 변경

ce4f1a7

refactor: 메서드 명 변경

9749150

refactor: 불 필요한 @component 제거

daea6cf

refactor: 메서드 개선

10cd44b

refactor: TicketInfo 를 record 로 변경

48696c0

chore: record 명 변경

556c3ea

chore: 공백 추가

a000a92

refactor: DetailResponse 내부에 관련 record 를 선언한다.

2796e7c

seokjin8678 approved these changes Jan 7, 2024

View reviewed changes

carsago approved these changes Jan 8, 2024

View reviewed changes

BGuga merged commit 6cda92b into dev Jan 9, 2024
3 checks passed

BGuga deleted the feat/#643 branch January 9, 2024 13:56

		private static final int MOST_FAST_SEQUENCE = 1;
		private final int value;

[BE] feat: 의존성을 정리한다(#643) #644

[BE] feat: 의존성을 정리한다(#643) #644

Conversation

BGuga commented Dec 31, 2023

📌 관련 이슈

✨ PR 세부 내용

github-actions bot commented Dec 31, 2023 • edited Loading

Test Results

seokjin8678 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BGuga Jan 6, 2024 • edited Loading

Choose a reason for hiding this comment

BGuga Jan 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carsago left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carsago Jan 4, 2024 • edited Loading

Choose a reason for hiding this comment

BGuga Jan 6, 2024 • edited Loading

Choose a reason for hiding this comment

xxeol2 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seokjin8678 left a comment

Choose a reason for hiding this comment

carsago left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Dec 31, 2023 •

edited

Loading

seokjin8678 left a comment •

edited

Loading

BGuga Jan 6, 2024 •

edited

Loading

BGuga Jan 6, 2024 •

edited

Loading

carsago Jan 4, 2024 •

edited

Loading

BGuga Jan 6, 2024 •

edited

Loading