인프런 커뮤니티 질문&답변
작성자 없음
작성자 정보가 삭제된 글입니다.
Service 계층과 Repository 계층 사이의 Cache 레이어
작성
·
21
0
안녕하세요 개발 하다 고민이 생겨서 질문 남깁니다
예를 들어, Player 도메인에 대한 서비스를 개발하는 상황입니다.
기존에는 PlayerService가 PlayerCache, PlayerRepository 를 의존하여 updatePlayerName 메소드가 호출되었을 때, PlayerRepository에서 update 해주고, PlayerCache에서 캐시를 갱신해 주었습니다.
그런데 여기서 예를 들어, NicknameCouponService 라는 서비스에서 Player 도메인에 대한 update를 발생시키고 싶을 때, PlayerRepository와 PlayerCache 를 동시에 의존해야 한다는 것을 항상 기억하고 수행해 주어야 하는 문제가 발생하였습니다.
이 문제 때문에 캡슐화가 되지 않아 프로젝트 복잡성이 증가하는 것 같고, 그렇다고 update를 항상 PlayerService를 통해만 진행하게 된다면, PlayerRepository의 재사용성이 떨어지게 되는 것 같습니다.
그러면 결국 Service 계층과 Repository 계층 사이에 Cache기능이 있는 Repository역할을 수행하는 계층이 필요하다고 느끼게 되었는데, Cache가 트랜잭션에 영향을 또 주지 않아야 하니까 트랜잭션을 처리하는 서비스 레이어의 영역을 또 침범하게 되는 것 같고... Coroutines + Webflux 환경이라 Aop로 캐시추상화 또한 사용하지 못하고 있습니다.
실무에서는 어떻게 해결하는지 궁금합니다!
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
off님께서 고민하고 계신 Service와 Repository 계층 사이의 캐시 레이어 문제는 많은 개발자들이 직면하는 상황입니다. 일반적으로 서비스 계층의 캡슐화를 유지하면서도 캐싱의 복잡성을 줄이기 위해 몇 가지 접근법을 고려할 수 있습니다.
캐시 레포지토리 패턴: 서비스 계층과 레포지토리 계층 사이에 캐시가 포함된 레포지토리 구현을 제공하는 것이 한 가지 방법입니다. 이를 통해 캐시는 레포지토리 레벨에서 관리되고, 서비스 계층에서는 여전히 하나의 인터페이스로 도메인을 처리할 수 있습니다. 캐시와 데이터베이스의 일관성을 유지하기 위해 트랜잭션 내에서 캐시를 갱신하거나 무효화할 수 있습니다.
도메인 이벤트와 캐시 갱신: NicknameCouponService와 같은 다른 서비스에서 Player 도메인을 업데이트할 때 도메인 이벤트를 사용하여 변경 사항을 알리고 이를 기반으로 캐시를 업데이트하는 방법도 있습니다. 이를 통해 동시성 문제를 줄이고 서비스 간 결합도를 낮출 수 있습니다.
Spring의
@Cacheable,@CachePut,@CacheEvict: Spring 생태계에서 캐시 추상화 기능을 사용하는 경우 서비스나 레포지토리 계층 내에서 메소드에 주석을 달아 간단하게 캐시를 관리할 수 있습니다. Webflux 환경에서 바로 사용하기 어렵다면, Redis와 같은 외부 캐시로 레이어를 구성하거나 Reactor의SwitchOnFirst와 같은 메서드를 활용한 캐시 전략을 고려해보세요.
실무에서 어떠한 특정 패턴을 선택할지는 사용 중인 아키텍처, 트랜잭션 관리 요구사항, 그리고 팀의 개발 관행에 따라 달라질 수 있습니다. 위의 접근법들을 조합적으로 사용하여 복잡성을 줄이고, 유지 보수성을 높이는 방안을 찾아보시는 것을 권장 드립니다.
추가적으로, 적용 사례에 대한 더 많은 정보를 원하신다면 Spring Caching 관련 문서를 참조하실 수 있습니다.
도움이 되었길 바랍니다!