웹소설 서비스 만들기-2

사진: Unsplash 의 Jacek Dylag

구조잡기

• 처음 아무것도 없는 곳에서 시작을 하면 여러 생각이 듭니다. 대략 필요한 기술들(spring, jpa 같은 것들을 넣고) 넣고나면 프로젝트 구조는 어떤식으로 하면 좋을까는 항상 고민된다.
  Layer VS Domain
  멀티모듈, 핵사고날 선택지는 많은데, 시간대비 유지보수하기 좋게 해볼 구조는 역시 도메인 구조를 잡는 것이 좋은 것 같습니다.

인증, 도서, 주문, 상품, 사용자의 도메인에서 개발을 진행하기로 했습니다.

빌드 테스트 설정

• 빨리 만드는 것만큼 서비스 안정 중요합니다. 기능별 테스트코드를 작성하고, 테스트 코드를 통과해야 브랜치에 머지가 되게 설정합니다.
• PR을 보내는 순간, CHAT GPT가 자동 리뷰를 진행합니다. 유용한 것을 떠나서 혼자서 심심하지 않습니다.
• 테스트 코드는 현재 필요한 만큼 작성합니다. 커버리지보다 필요한 기능에 테스트.

도서기능 개발

• 혹시 서비스가 잘되서 소설이 아니라 만화책을 제공한다면? Novel로 시작했다가 바로 수정했습니다.
• 개발하면서 캐싱 기능이 있으면 좋을 것 같습니다.

캐싱

Redis vs Caffeine?

• https://redis.io
• https://github.com/ben-manes/caffeine

고를 수 있다면 Redis를 고르고 싶지만, Redis 설치 작업을 해야합니다. EmbededRedis를 사용할 수 있지만, 이미 업데이트가 끊긴지 오래고
도커로 새로 띄우자니 번거로운 작업이 될 것 같다. 카페인을 사용하면 로컬의 서버 자원을 이용합니다.
Caffeine 작업이 번거로운 것이 아니기 때문에 적용해봤습니다.

데이터가 얼마없더라도 110ms -> 11ms 로 응답시간이 바로 줄어듭니다.

에피소드 읽기

• 에피소드는 유료 모델이기때문에 에피소드(회차)를 보기위해서는 티켓을 가지고 있어야합니다.
  그렇다면 도서에서 책을 불러오고, 사용자가 가진 티켓을 차감해야합니다. 사용자 티켓까지 차감하면 코드도 길어지고, 도메인으로 나눈 의미가 줄어들게됩니다. 이럴때 스프링 이벤트를 사용했습니다.

public EpisodeResponse getEpisode(Long bookId, Long userId, Long episodeId) {
        final Book book = findBook(bookId);
        book.onSaleCheck();
        Episode episode = book.getEpisode(episodeId);
        if (episode == null || !episode.canSubscribe()) {
            throw new InvalidValueException("현재 에피소드를 읽을 수 없습니다.");
        }
        eventPublisher.publishEvent(new EpisodeSubscribeEvent(episodeId, userId, episode.getTicketPrice()));
        return new EpisodeResponse(episode);
}

덕분에 코드가 간결해졌습니다. 이벤트를 통해, 사용자가 현재 티켓을 구매할 수 있는지 체크하고 응답을 내려줍니다.

사용자 서비스에서는 티켓을 차감하고, 내 도서(user_book)에 에피소드 정보를 기록합니다.