SPRING

스프링을 사용한 프로젝트에서 종종 보이는 어노테이션에 사용한 의존성 주입의 남용과 오랜 세월의 흐름으로 의도치 않게 서비스 간의 의존성 그래프가 복잡하게 강결합으로 묶이면서 코드를 읽기도 어렵고 단위 테스트를 구성하기도 어려운 상황이 생긴다. 아래는 어떤 백엔드 서비스의 의존성 그래프다. 순환 종속성이 포함된 복잡한 왼쪽의 의존성 그래프를 오른쪽의 단순한 의존성 그래프로 리팩터링하여 라이브 서비스에 반영하였다. 이번 글은 오랜 세월의 흐름으로 서비스 의존성 그래프가 복잡해진 라이브 서비스를 리팩터링한 내용을 일반화하여 작은 예제로 만들어서 정리한다....

해당 코드는 Github 공개되어 있습니다. 용어 명칭 설명 라우트(Route) 라우트는 목적지 URI, 조건자 목록과 필터의 목록을 식별하기 위한 고유 ID로 구성된다. 라우트는 모든 조건자가 충족됐을 때만 매칭된다 조건자(Predicates) 각 요청을 처리하기 전에 실행되는 로직, 헤더와 입력돤값 등 다양한 HTTP 요청이 정의된 기준에 맞는지를 찾는다. 필터(Filters) HTTP 요청 또는 나가는 HTTP 응답을 수정할 수 있게한다. 다운스트림 요청을 보내기전이나 후에 수정할 수 있다. 라우트 필터는 특정 라우트에 한정된다....

동일한 Bean 내에서 @Transactional 을 사용하는 경우 예상했던 것과 다르게 동작할 수 있습니다. 발생 원인과 해결 방법에 대해서 정리한 포스팅입니다. 위 코드는 Controller 에서 something() -> save() 을 차례대로 호출하는 코드입니다. save() 메서드에서는 특정 경우 RuntimeException 을 발생시키고 있습니다. save() 메서드에 @Transactional 때문에 해당 반복문 전체에 트랜잭션이 묶이게 되고 예외가 발생하면 전체가 Rollback될 것이라고 예상됩니다. 위 와 같이 해당 컨트롤러를 호출하고 결과를 조회하면 아래와 같습니다....

해당 코드는 Github 에서 확인할 수 있습니다. 대부분의 애플리케이션은 외부 인프라스트럭처와 통신하면서 진행됩니다. 대표적인 외부 스트럭처는 외부 API들이 있습니다. 이런 외부 인프라스트럭처는 Mocking 해서 원하는 응답 값을 지정하고 검증하고 싶은 부분을 검증을 진행하는 것이 흔한 패턴입니다. 대표적으로 Mockito 프레임워크가 있으며 Mock 테스트는 Spring Guide - 테스트 전략 : Service 테스트 , RestTemplate Mock 기반 테스트 하기 에서 포스팅한 적 있습니다. 그런데 이런 식의 Mock 테스트 코드는 문제없지만, 실제 구동 환경(Local, Sandbox, Beta)에서는 문제가 있을 수 있습니다....

최근 JPA를 3년 가까이 사용하면서 개인적인으로 선호하는 패턴들을 한 번 정리하려고 한다. 어디까지 개인적으로 선호하는 패턴으로 굳이 이런 가이드를 따르지 않아도 된다. 컬럼 에노테이션 사용 칼럼 에노테이션과 멤버 필명이 동일한 경우 칼럼에노테이션을 생략하는 경우도 있다. 그래서 일치하지 않은 것들만 작성하는 방법도 있지만 나는 모든 멤버 필드에 칼럼 에노테이션을 작성하는 패턴을 선호한다. 칼럼 에노테이션을 통해 nullable , unique ,...

스프링 프로젝트에서는 외부 API 모듈을 RestTemplate를 이용해서 호출하는 경우가 많습니다, 이런 경우 RestTemplate을 기반으로 Mock 테스트를 보다 쉽게 진행할 수 있습니다. 왜 Mock 기반 테스트를 진행 해야하나 ? 외부 인프라스트럭처를 테스트 코드를 작성할 때는 mock 기반으로 테스트를 진행해야 합니다. 외부 인프라스트럭처에는 대표적으로 외부 API가 있습니다. 그런데 왜 Mock 기반으로 테스트해야 할까요? 외부 환경이기 때문에 제어권이 우리 밖에 있습니다. 그래서 우리 코드의 테스트를 위해서 Request, Response가 우리가 주어진 값인 경우 정상 동작하는지 테스트하기 위함입니다....

해당 코드는 Github 를 확인해주세요. Spring boot 2.2 버전부터는 Junit5 디펜던시를 기본으로 포함하고 있습니다. Junit5 주요 테스트 어노테이션과 Spring boot에서 활용법을 정리해보았습니다. @ValueSource @ValueSource 어노테이션을 사용하면 배열을 값을 테스트 메서드로 손쉽게 전달할 수 있습니다. Int, String 이 이외에도 기본형 데이터 타입을 지원하고 있습니다. EnumSource @EnumSource 어노테이션을 통해서 Enum을 효율적으로 테스트 할 수 있습니다. 각 분기를 뜻하는 Enum을 위와 같이 정리했습니다....

해당 코드는 Github 에 공개되어 있습니다. 스프링에서는 JSR 303 기반 어노테이션 기반으로 일관성 있는 Validation을 진행할 수 있습니다. 하지만 @NotNull , @NotEmpty , @Email 과 같은 검증은 가능하지만 비즈니스적에 맞는 Validation은 별도로 진행해야 합니다. 예를 들어 주문에 대한 결제 정보를 받는 경우 카드 결제 시에는 카드 정보, 무통장 결제에는 계좌 정보를 입력받아야 합니다. 해당 요청을 JSON으로 표현하면 아래와 같습니다. 무통장 결제 카드 결제 위 JSON 같이...

Spring WebFlux와 Kotlin으로 만드는 Todo 서비스 – 1편 Spring WebFlux와 Kotlin으로 만드는 Todo 서비스 – 2편 Spring WebFlux와 Kotlin으로 만드는 Todo 서비스 – 테스트 슬라이스 적용하기 개요 지난 예제들에선 간단한 Todo 예제를 만들고 개선해봤습니다.  또한 그렇게 만들어진 예제의 CRUD를 curl을 이용해 동작을 검증하였습니다.  하지만 변경 사항이 발생하였을 경우 매번 애플리케이션을 재기동 하여 잘 동작하는지 확인해야 했고 각각의 모듈이 어떤 기능을 하는지 알기 어려웠으며, 정상 수행에 대한 피드백을 빠르게 얻기 힘들었습니다. 물론 현재는 작은 규모의 프로젝트이지만 나중엔 기능을 추가하고 안정성을 강화해 프로덕션 규모의 큰 애플리케이션으로 바뀔 수도 있습니다. 이런 경우엔 테스트를 효율적으로 작성하는 전략이 중요해집니다. 이번 편에선 지난 예제를 기반으로  테스트를 작성해보면서 Spring Boot에서 지원하는...

비동기 메시지를 사용하여 상호 간에 통신하는 방식을 메시징 Messaging[1] 이라고 부른다. 마이크로서비스 환경에서 비동기 처리 시 보통 카프카 Kafka 나 래빗엠큐 RabbitMQ 같은 메시지 브로커 Message Broker 를 사용하여 메시징을 구현한다. 아래와 같이 마이크로서비스들이 메시징을 통해 협업하여 주문을 처리한다고 가정해보자. OrderService는 주문 상태 이벤트(예. ORDER_CREATED, ORDER_CANCELLED 등)를 메시지 브로커에 발행하고 이벤트에 관심 있는 서비스가 구독하여 처리한다. 주문 상태 이벤트의 발행은 두 가지로 구분할 수 있다....