Java, Spring

보통 Repository 를 설계할 때 아래와 같은 그림으로 설계를 할 것이다.위와 같은 구조는 Domain 에 Repository 인터페이스를 두고 Infrastructure 에서 해당 인터페이스를 구현하며 infra → domain 의 저수준 → 고수준 의 의존관계

이번 포스팅에서는 Enum 을 사용하다보면 마주할 수 있고, 모르고 당한다면 고통받을 수 있는 트러블 상황에 대해서 얘기하고자 한다. AvailableRent 코드 (BookState 를 변수로 들고있음)BookState enum 코드위 코드에서 아래 코드를 실행시키면

프록시란 '대리', '대신'이라는 뜻을 가지며 무언가를 중간에서 대신 해준다는 의미를 가지고 있다.즉 코드레벨에서 보자면 프록시 기술은 어떤 원본 객체가 해야할 작업을 대신 해주는 객체를 만드는 것이다.그렇다면 이러한 프록시 기술은 어떤 요구사항에서 출발 했을까 🤔요

단위 테스트는 해당 컴포넌트에 대해서만 진행하는 테스트이며 해당 컴포넌트에 있는 코드들만 테스트하면 된다.그래서 단위 테스트를 할 때 해당 컴포넌트에서 필요한 의존성만 있으면 된다. 즉 Application Context 에 모든 Bean 을 띄워주는 @SpringBo

프로젝트에 리뷰 기능이 존재하고, 리뷰에 좋아요를 할 수 있는 좋아요 기능이 포함돼있다.기존에는 리뷰의 좋아요 개수를 관리하는 likeCount 변수를 통해서 관리했다.하지만 likeCount 변수는 동시성 문제를 유발했다.현재 LikeReview 테이블은 아래와 같이

이번 포스팅에서는 스프링 부트 3.1.5 버전에서 Spring Security 를 통해 소셜로그인을 직접 적용해보며, 부트 최 신 버전에서 소셜로그인을 적용하는 방법과 내가 직접 적용해본 과정을 포스팅 해보려고 한다🫡소셜로그인에는 여러 인증 방식이 있지만 나는 가장

이번에 티켓팅 프로젝트를 하면서 예매대기 기능과 랭킹 기능을 맡으며 스케줄러 모듈을 분리하여 서버를 별도로 구성하게 되었다그리고 스케줄러 서버의 failover 를 구현하기 위해 두 대 이상의 서버를 띄우는 방향으로 스케줄러 서버를 설계했다그런데 이는 문제가 있었다.