[우테코 5기] 장바구니 협업 미션 회고

라온, 쥬니, 세인, 쵸파랑 진행했던 레벨 2 마지막 미션, 장바구니 협업 미션이다!

프론트 크루분들이랑도 함께 할 수 있었어서 너무 재밌었던 시간이었다 😊

이번 미션은 저번에 진행했던 미션을 바탕으로 하다 보니까 코드적인 부분보다, 배포 쪽을 더 신경썼던 것 같다.

마지막 미션인 만큼 정말 많이 배웠던 시간이었다 ㅎㅎ

 

---

 

✔️ 작성한 코드

GitHub - Cl8D/jwp-shopping-order: 우아한테크코스 레벨 2 장바구니 협업 미션 레파지토리

 

✔️ PR

[2단계 - 주문 기능 구현] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #19 · woowacourse/jwp-shoppi

 

마지막 코드 리뷰라는 게 너무 슬프다... 🥲

 

---

 

✔️ 기능 요구사항

- AWS로 배포하기 (서버 배포용 인스턴스 / DB용 인스턴스)

: 이때, DB용 인스턴스는 외부 IP로 공개되지 않는다.

- 장바구니에 담은 상품을 주문할 수 있다.
- 상품 주문 시 현실 세계의 쇼핑 서비스가 제공하는 재화 관련 요소를 최소 1가지 이상 추가한다.
: 재화 관련 요소: 쿠폰, 포인트, 할인 등
ex) 5만원 이상 주문 시 전체 금액에서 10% 할인이 된다.
- 사용자 별로 주문 목록을 확인할 수 있다.
- 특정 주문의 상세 정보를 확인할 수 있다.

 

---

 

✔️ AWS 배포 및 협업 환경 구축하기

프론트엔드 크루분들과 협업한다는 생각에 신나서 배포 쪽을 열심히 다루었다.

거의 다 블로그로 올린 내용이어서 따로 설명하지는 않고 넘어가고자 한다.

 

 

1. HTTP -> HTTPS 적용하기 (SSL / Nginx로 리버스 프록시 적용하기)

[Infra] AWS 배포 후 도메인 연결 및 HTTPS 적용, nginx로 리버스 프록시 적용하기

 

 

2. 젠킨스로 CI / CD 구축하기

[Jenkins] AWS 인스턴스를 젠킨스로 배포해보기 - 1편

 

[Jenkins] AWS 인스턴스를 젠킨스로 배포해보기 - 2편

 

 

3. Logback으로 에러를 파일로 로깅하기

[Spring] 에러 로깅하기 - Logback을 사용해서 ERROR 레벨만 파일로 로그를 남겨보자!

 

기초 중에 기초지만, 내 손으로 직접 배포를 해본다는 게 너무 뿌듯하고 신기했던 경험이었다 😶

다음 프로젝트 할 때는 서버만 있다면...! 더 멋있게 구축해야겠다 ㅎ_ㅎ

 

---

 

💬 도메인 설계하기 - 인터페이스로 분리하기

이번 미션의 핵심 요구사항 중에 하나가 재화 정책을 결정하는 것이었다.

우리 팀은 '쿠폰'이라는 도메인을 선택하였고, 처음으로 가입했을 때와 처음으로 상품을 주문했을 때 발급받도록 진행하였다.

쿠폰 도메인을 더 활용하면 좋았을 것 같은데, 최대한 간결한 방향으로 진행하다 보니 이렇게 됐다 🥲

 

또한, 예제 코드와 비슷한 듯 다르게 도메인을 설계하였다.

 

그림으로 나타내니까 복잡해 보이는데, 쿠폰과 주문, 환불 정책 도메인이 추가된 거 빼고는 지난 미션과 거의 다를 게 없다.

환불 정책의 경우 지하철 미션에서 진행했던 정책 관리 클래스의 방법을 그대로 따랐다. 마음에 든다!

 

- 한 가지 아쉬운 건, 주문 도메인이 장바구니 아이템 도메인 대신에 별도의 주문 상품 도메인을 가지고 있던 게 더 어울리지 않았을까 싶다. 주문이 완료된 이후에 주문에 대해 조회를 해올 때 장바구니 아이템 도메인을 가지고 있다 보니 논리적으로 어색하다는 느낌이 들었기 때문이다... 🥲 물론 리뷰어님은 별다른 피드백을 주시지 않았지만, 개인적으로 다음에 구현한다면 분리할 포인트라고 느껴졌다.

 

 

💡 도메인과 ID

또한, 도메인이 id를 가지고 있도록 만들었는데, 사실 처음에는 이 부분을 분리했다가 나중에 피드백을 받고 수정했다.

(몇몇 크루분들도 내가 설계한 것을 보고 말씀을 해주셨었는데, 최종적으로는 가지고 있는 구조로 만들었었다 ㅎㅎㅎ)

내가 너무 영속성 레이어의 값을 도메인 객체가 가지고 있는 것에 집착했었다는 게 느껴졌다... ㅎㅎ

JPA를 쓰다 보면 어차피 일어날 수밖에 없는 것이고, 오히려 분리함으로서 복잡도가 증가한 것이 사실이니까...

앞으로도 개발하면서 이렇게 분리하는 경우는 거의 없지 않을까 싶다. 또 다시 엔티티 객체에 대해서 고려해볼 수 있던 시간이었다 ㅎㅎ

 

 

💡 인터페이스 활용하기

또 한 가지 특이한 점은 인터페이스로 풀어나간 점인데, 우선 사용자의 비밀번호부터 보자.

public interface MemberPassword {

    String getPassword();
}

위와 같이 사용자의 비밀번호에 대한 인터페이스를 선언해두었다.

 

이는, 사용자가 회원가입 시 입력하는 비밀번호에 대한 제약 조건에 의해 생성자에서 객체를 만들 때 검증하게 되는데, DB에서 조회해온 값 (암호화 적용)으로 도메인 객체를 만들게 되면 제약 조건이 필요없으니, 별도의 메서드를 만드는 게 꽤나 번거롭다고 느껴졌기 때문이다.

또한, 암호화가 되어 있는 비밀번호와 암호화가 되지 않은 비밀번호가 하나의 객체로서 표현되는 게 2개의 책임을 가지고 있다고 느껴졌기 때문에, 상태가 다른 객체로서 표현하는 게 좋다고 생각했다.

 

그래서 아래와 같이 각각에 대한 구현체를 분리하였다.

public class NaturalPassword implements MemberPassword {

    private final String password;

    ...

    public static NaturalPassword create(final String password) {
        validatePassword(password);
        return new NaturalPassword(password);
    }

    private static void validatePassword(final String password) {
        if (password.length() < PASSWORD_MIN_LENGTH || password.length() > PASSWORD_MAX_LENGTH) {
            throw new BadRequestException(MEMBER_PASSWORD_LENGTH);
        }
    }
}

이거는 사용자의 입력으로 들어온 비밀번호 객체이다. validatePassword 메서드를 통해 길이를 검증하였다.

public class EncryptedPassword implements MemberPassword {

    private final String password;

    ...
    
    public static EncryptedPassword create(final String password) {
        return new EncryptedPassword(password);
    }
}

반면에, 암호화된 비밀번호를 담는 객체이다. 별도의 검증 없이 바로 객체를 생성하도록 만들었다.

참고로, 비밀번호 암호화의 경우 SHA256을 통해서 진행하였다. (현재 우리 구조상 원본 비밀번호를 알 이유가 없기 때문에 복호화가 안 되는 알고리즘을 채택하였다.)

public static String encrypt(final String target) {
    try {
        final MessageDigest md = MessageDigest.getInstance("SHA-256");
        md.update(target.getBytes());
        return bytesToHex(md.digest());
    } catch (NoSuchAlgorithmException ignored) {
        throw new RuntimeException("암호화 중 오류가 발생하였습니다.");
    }
}

 

추가적으로 주문 역시 인터페이스로 구현하였는데, 사용자의 비밀번호와 같은 이유로 쿠폰을 사용한 주문과, 쿠폰을 사용하지 않은 주문으로 분리하였다.

public class CouponOrder implements Order {

    ...
    private final Coupon coupon;

    // 총 주문 금액을 계산하는 메서드
    private BigDecimal calculateTotalOrderPrice() {
        return OrderPriceCalculator.calculateTotalOrderPrice(cartItems);
    }
	
    // 쿠폰에 의해서 할인된 금액을 계산하는 메서드
    private BigDecimal calculateDiscountPrice() {
        final int discountRate = coupon.discountRate();
        final BigDecimal convertedDiscountRate = BigDecimal.valueOf(
            (PERCENTAGE - discountRate) * DECIMAL_CONVERSION);
        return totalPrice.multiply(convertedDiscountRate).setScale(0, RoundingMode.DOWN);
    }
}

쿠폰을 사용한 주문은 쿠폰 도메인에 대한 의존 관계를 추가적으로 가지고 있으며, 쿠폰에 의해 할인된 금액도 함께 관리한다.

다만, 주문에 대한 필드가 늘어나면서 인터페이스의 getter가 엄청 많아졌다는 단점은 있다.

이에 대해서 다르게 풀어나가고 싶었는데, 명시적인 연관관계를 인터페이스로 형성하지 않았다면 해결할 수 있었을까 싶긴 하다.

아니면, 공통되는 필드를 관리하는 OrderDetail 같은 객체를 만들어서 관리했으면 더 좋았을 것 같다.

 

---

 

💬 예외 클래스 설계하기

사실 이전부터 나를 괴롭히던 주제 중에 하나였다. '예외에 관한 클래스에 어떤 정보까지 가지고 있어야 하는가?'

개인적으로 서버에서 던지는 예외 메시지는 사용자에게 출력되는 용도보다는, 클라이언트 개발자가 확인하는 메시지고, 클라이언트 개발자가 해당 메시지에 따라서 사용자에게 보여지는 메시지를 관리해야 한다고 생각했다.

하지만 리뷰어님은 오히려 2번을 더 선호하셨다.

생각해보면 내가 아직 큰 서비스를 경험해보지 못해서 1번을 더 선호하는 건가 싶기는 하지만... 😅

위와 같은 상황이 주어졌을 때 사용자에게 '상품 ID 1번이 존재하지 않습니다' 같은 메시지는 적합하지 않다고 생각했다.

예전에 개발했을 때는 클라이언트에게 에러 코드 모음을 내려주는 전용 api가 있어서, 해당 api 정보를 바탕으로 클라이언트가 매칭시켜줬던 기억이 난다. 아마 이 부분은 클라이언트 개발자과 계속 협의하면서 바꾸어나가지 않을까 싶다 😶

 

또한, 이번에 작성한 예외 클래스에서는 상태 코드를 함께 관리하도록 만들었다.

public class ForbiddenException extends RuntimeException {

    private static final HttpStatus httpStatus = HttpStatus.FORBIDDEN;
    private final ErrorCode errorCode;
    ...
}

덕분에 ExceptionHandler에서의 코드가 줄어서 마음에 든다. 지금까지는 왜 이런 생각을 못 했을까...! 🥲

앞으로도 이런 식으로 작성하지 않을까 싶다. (errorCode는 협의하는 거에 따라 달라질 것 같다!)

 

---

 

💬 쿠폰 발행 - 도메인 이벤트 활용하기

전에 말랑의 테코톡 보고 이벤트 방식을 꼭 활용해보고 싶었는데, 쿠폰 발행에 대해서 이벤트 방식을 사용하면 좋을 것 같다는 생각이 들어서 바로 도입해보았다. 개인적으로 매우 뿌듯했다... 😶

 

도메인 이벤트를 활용한 배경은 다음과 같다.

 1. 쿠폰 발행의 경우 다양한 서비스에서 활용할 수 있는 비즈니스 로직이다. 
다른 서비스에서 사용할 때마다 쿠폰에 대한 의존 관계가 뻗어나가는 것보다, 이벤트 방식을 통해 의존성을 역전시키는 게 더 깔끔할 것 같다고 생각했다.

2. 회원가입과 쿠폰 발행이 하나의 트랜잭션으로 묶여있을 때, 쿠폰 발행 중에 예외가 발생했다면 회원가입 로직까지 롤백이 될 것이다. 사용자의 입장에서 회원가입은 굉장히 번거로운 작업이고, 사용자가 가입하는 시점에서는 쿠폰이 발행된다는 것을 알지 못하기 때문에 쿠폰 때문에 회원가입 자체가 실패해버리면 다시 가입하지 않을 것이라는 생각이 들었다. 이를 위해 가입 로직과 쿠폰 발행 로직에 대한 트랜잭션을 분리할 필요성을 느꼈다.

그래서, 아래와 같이 회원 가입 시 쿠폰 발행을 진행하도록 이벤트를 발행하였다.

@Transactional
public long save(final MemberJoinRequest memberJoinRequest) {
    if (memberRepository.existByName(memberJoinRequest.getName())) {
        throw new BadRequestException(ErrorCode.MEMBER_DUPLICATE_NAME);
    }
    final Member member = convertMember(memberJoinRequest);
    final long savedMemberId = memberRepository.insert(member);
    applicationEventPublisher.publishEvent(new JoinMemberCouponEvent(savedMemberId));
    return savedMemberId;
}

그리고, 쿠폰 저장 로직은 아래와 같이 진행하였다.

@TransactionalEventListener
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveJoinMemberCoupon(final JoinMemberCouponEvent joinMemberCouponEvent) {
    final Long memberId = joinMemberCouponEvent.getMemberId();
    final Coupon coupon = couponRepository.findByNameAndDiscountRate(JOIN_MEMBER_COUPON.getName(),
        JOIN_MEMBER_COUPON.getDiscountRate());

    final LocalDateTime issuedAt = LocalDateTime.now();
    validateAlreadyIssued(memberId, coupon.couponId());
    final MemberCoupon memberCoupon = convertMemberCoupon(coupon, issuedAt);
    memberCouponRepository.save(memberId, memberCoupon);
}

로직 자체는 쿠폰을 조회해서 이미 발생했는지 확인하고 저장한다.

💡 @TransactionalEventListener란?
- phase 옵션을 통해서 트랜잭션에 따른 이벤트 처리 방법을 지원한다. 
기본적으로는 'AFTER_COMMIT'으로 설정되어 있기 때문에 트랜잭션 커밋 시 이벤트를 실행한다.

 

하지만, 여기서 @Transactional(propagation = Propagation.REQUIRES_NEW)라는 옵션이 눈에 띌 것이다.

기존에는 전파 속성을 설정하지 않았었는데, 리뷰어님께 다음과 같은 피드백을 받았다.

왜 그럴까 고민을 했었는데, 나는 아래와 같이 이해했다.

1. JdbcTemplate의 경우 @transactional 어노테이션이 없어도 기본적으로 jdbcTemplate.update나 query() 메서드를 사용하는 시점에서 DB에 쿼리가 날라간다. (JPA와 다른 점)

2. 예외가 발생했을 때 롤백이 일어나기 위해서는 @transactional을 통해서 묶어줘야 한다. 아니면 JdbcTemplate에서 이미 save를 진행했기 때문에 이에 대해 롤백할 수 없다.

3. 기본적으로 @TransactionalEventListener는 시작된 트랜잭션 commit 후에 동작한다.

4. 하지만, 단순히 @transactional을 붙이면 기존 회원 가입에서 걸려있던 트랜잭션에 참여하게 된다. 그러나, 커밋된 트랜잭션에 대해서는 다시 커밋이 불가능하기 때문에 롤백이든, 다른 연산을 수행하더라도 무의미하다.
-> 그래서 만약 JPA 같이 삽입, 수정, 삭제 연산에서 @Transcational이 필요한 경우였다면 애초에 쿼리 자체가 날라가지 않았을 것이다. (물론 나의 가정이다)

5. ⭐️ 하지만, 지금은 jdbcTemplate을 사용했기 때문에 쿼리는 날라간다. 하지만, 예외 발생 시 롤백이 불가능하다.

6. 이를 해결하기 위해 기존의 트랜잭션과 다른 트랜잭션으로 분기시켜서 예외 발생 시 롤백이 되도록 만든다!

원래는 이미 커밋된 트랜잭션에 참여하기 때문에 수정이든 삭제든 불가능하지만 (JPA 같이 영속성 컨텍스트를 통해서 flush가 발생하는 경우), jdbcTemplate의 경우 트랜잭션 어노테이션에 상관없이 쿼리를 execute 하는 순간 DB에 쿼리가 날라가기 때문에 @Transactional 어노테이션이 없어도 저장 자체는 잘 되었다.

하지만, 예외가 발생했을 때 '이미 커밋된 트랜잭션'에 참여했기 때문에 롤백 역시 불가능하게 된 것이다.

 

그래서, 트랜잭션 전파 속성을 활용하여 별도의 트랜잭션으로 분기해주었다.

트랜잭션은 기본적으로 전파 속성이 'REQUIRED'로 설정되어 있기 때문에, 기존 트랜잭션이 있으면 해당 트랜잭션에 참여한다. (없으면 새로 생성) 반면에, REQUIRES_NEW를 사용하게 되면 항상 새로운 트랜잭션에서 실행된다.

두 트랜잭션이 분리되었기 때문에 B의 롤백이 A에는 영향을 끼치지 않게 되었으며, 덕분에 쿠폰 발행 도중 예외가 발생하더라도 회원가입 로직과 관계 없이 잘 롤백되는 것을 확인할 수 있었다.

 

아래는 이에 대한 테스트 코드이다.

회원 가입 시 이미 발행된 쿠폰이 있다면 예외가 발생하고, 해당 쿠폰에 대해서 다시 발급이 되는지 테스트한다.

@Test
@DisplayName("회원 가입 축하 쿠폰 발행 시 이미 발행이 완료되었다면 예외가 발생한다.")
void saveJoinMemberCoupon_already_issued() {
    // given
    final String 져니_이름 = "journey2";
    final Long 저장된_져니_아이디 = 사용자를_저장한다(져니_이름);
    final JoinMemberCouponEvent 회원_가입_쿠폰_발행_이벤트 = new JoinMemberCouponEvent(저장된_져니_아이디);
    memberCouponService.saveJoinMemberCoupon(회원_가입_쿠폰_발행_이벤트);

    // then
    assertThatThrownBy(() -> memberCouponService.saveJoinMemberCoupon(회원_가입_쿠폰_발행_이벤트))
        .isInstanceOf(BadRequestException.class)
        .extracting("errorCode")
        .isEqualTo(ErrorCode.COUPON_ALREADY_EXIST);

    // then
    final List<MemberCouponDto> 져니_쿠폰들 = memberCouponDao.findMyCouponsByName(져니_이름);
    assertThat(져니_쿠폰들)
        .hasSize(1);
}

예외 발생 후 쿠폰을 조회했을 때 이미 발행된 1장의 쿠폰만 존재하는 것을 확인할 수 있다.

 

---

 

💬 주문 취소 정책 설계하기

사실 이거는 페어 프로그래밍으로 진행한 건 아니고, 내가 따로 만들고 싶어서 만든 api이다.

주문한 지 3일 이내라면 전액, 7일 이내라면 반액을 반환하도록 만들었다. 물론 그 이상은 환불 불가능하다.

사실 배송 정책이 있다면 배송 출발 같이 그런 것까지 고려하겠지만... 현재 서비스 특성상 거기까지 뻗어나가지 않았기 때문에 이것 역시 간결하게 구현하였다. (이번 미션을 하면서 제대로 된 쇼핑몰 사이트를 만들어보고 싶다는 생각이 들었다 😶)

 

// Before
public RefundPolicyComposite refundPolicyComposite(
    final RefundPolicy fullRefundPolicy, final RefundPolicy halfRefundPolicy) {
    return new RefundPolicyComposite(
        List.of(fullRefundPolicy, halfRefundPolicy)
    );
}

// After
public RefundPolicyComposite refundPolicyComposite(final List<RefundPolicy> refundPolicies) {
    return new RefundPolicyComposite(refundPolicies);
}

정책 관련 클래스를 빈으로 주입할 때 기존에는 RefundPolicy에 대해서 하나씩 집어넣었는데 매번 Config를 수정해야 한다는 단점이 존재해서 아래와 같이 List를 통해서 주입받도록 변경하였다.

 

이렇게 하면 컴포넌트 스캔 순서대로 등록이 되어서 (사전순으로 보인다) Full, Half가 빈으로 주입되었다. 스캔 순서에 따른 빈에 대한 순서 보장이 확실하지 않기 때문에 정책이 적용 가능한지 판단하는 메서드에 대해 경계값을 철저하게 검증하는 방향으로 변경하였다.

// Before - 50% 할인 시 3일 이상인지만 검증
@Override
public boolean isAvailable(final Order order, final LocalDateTime currentTime) {
    return currentTime.isBefore(order.getOrderedAt().plusDays(HALF_REFUND.getDay()));
}

// After - 3일 ~ 7일인지 검증
@Override
public boolean isAvailable(final Order order, final LocalDateTime currentTime) {
    final LocalDateTime orderedAt = order.getOrderedAt();
    return currentTime.isAfter(orderedAt.plusDays(FULL_REFUND.getDay())) &&
        currentTime.isBefore(orderedAt.plusDays(HALF_REFUND.getDay()));
}

 

또한, 금액의 경우 정밀한 계산을 해야 하기 때문에 BigDecimal을 사용하는 게 좋다고 들어서 요렇게 적용하였다.

@Override
public BigDecimal calculatePrice(final BigDecimal price) {
    final BigDecimal refundRate = BigDecimal.valueOf((PERCENTAGE - HALF_REFUND_RATE) * DECIMAL_CONVERSION);
    return price.multiply(refundRate).setScale(0, RoundingMode.DOWN);
}

setScale(0, RoundingMode.DOWN)을 통해서 소수점 이하의 값을 버리도록 만들었다. (아니면 값이 더러워진다!)

 

---

 

💬 페이징 쿼리 작성하기

이 부분도 합의된 API는 아니고, 개인 학습용으로 작성했다.

항상 JPA로 만들었다가 쌩 쿼리로 작성해본 건 처음이었는데, 생각보다 어렵지 않았다.

@GetMapping("/pages")
public ResponseEntity<ProductPageResponse> getProductsByPage(@RequestParam("page") final int page,
                                                             @RequestParam("size") final int size) {
    return ResponseEntity.ok(productService.getProductsByPage(page, size));
}

상품 목록에 대한 페이징 API이다. 쿼리 파라미터로 조회할 페이지 번호와 한 페이지에 몇 개씩 받을 것인지 입력받았다.

 

public class ProductPageResponse {

    private final long totalPage;
    private final List<ProductResponse> productResponse;
    ...
}

반환 값으로는 총 페이지 수와 해당 페이지에 대한 상품 응답을 반환하였다.

 

public List<ProductEntity> getProductsByPage(final int page, final int size) {
    final int offset = calculateOffset(page, size);
    final String sql = "SELECT id, name, image_url, price, is_deleted FROM product "
        + "ORDER BY id LIMIT ? OFFSET ?";
    return jdbcTemplate.query(sql, productEntityRowMapper, size, offset);
}

나름 핵심이 되는 페이지 처리 쿼리다.

⭐️ LIMIT의 경우 결과 중에서 몇 개만 조회할 것인지 설정하고, OFFSET은 어디서부터 가져올지를 나타낸다.

SELECT * FROM table_name LIMIT 10 OFFSET 20;
= 20번째 (계산된 오프셋) 행부터 10개 (size) 조회
= 21번째 ~ 30번째 행까지 출력

 

여기서 offset을 계산하는 메서드를 호출했는데, 이는 다음과 같다.

private int calculateOffset(final int page, final int size) {
    if (page == 1) {
        return 0;
    }
    return (page - 1) * size;
}

 

클라이언트 개발자에게 1부터 값을 받는다고 가정하였다.

1이라면 첫 번째 페이지니까 offset을 0을, 그 이상이라면 (page - 1) * size만큼을 설정해주었다.

만약 page = 3, size = 10이라는 값이 들어왔다면 2 * 10 = 20번째 행부터 10개를 가져오게 되는 것이다.

 

총 페이지의 경우 다음과 같이 계산하였다.

private long calculateTotalPage(final int size, final long totalProductCount) {
    long totalPage = totalProductCount / size;

    if (totalProductCount % size > 0) {
        totalPage++;
    }
    return totalPage;
}

상품의 총 개수에서 한 페이지에 출력할 상품의 개수를 나눈 값을 총 페이지로 설정하였다.

이때, 총 개수에서 한 페이지에 출력할 상품의 개수의 나머지 값이 0보다 크면 1을 증가시켜주었다.

이는, 총 25개의 상품이 있을 때 10개씩 한 페이지에 출력한다면 총 페이지는 3개이기 때문에 남은 값들에 대해 페이지로 처리해주려고 위와 같이 설정해주었다.

 

사실 page랑 size에 대해서도 제약 조건을 걸어둬야 하고 (0 이상이라든지, 정해진 값으로 size를 받는다든지...)

반환 값에도 현재 페이지랑 사이즈 같이 조금 더 다양하게 내려줬어야 했는데 개인 학습용이라 간단하게 만들었다. ㅎㅎ

나름 재밌었던 경험이었다!

 

---

 

이번 미션은 확실히 기존 코드 리팩터링 + 인프라 구축에 신경을 많이 써서 그런가 크게 회고할 내용이 없었다.

하지만 목표했던 도메인 이벤트도 써보고, 여러 가지로 배운 점이 많았어서 그런가 뿌듯했던 시간이었다.

마지막 미션인 만큼 열심히 했던 것 같아서 좋다!

 

레벨 2 회고도 얼른 쓰고 방학 신나게 놀아야지

😎