서비스 계층 간의 의존성
BudgetKeemi 프로젝트에서의 고민
코드를 작성하다보면 내가 사용하는 언어와 프레임워크 특징을 잘 사용하고 있는가에 대한 의문이 들때가 있다.
포트폴리오 만드는 취준생 입장에서 코드 리팩토링이나 비지니스 로직을 추가하는 경우가 많이 없다보니 내가 지금 작성한 코드가 일으킬 사이드 이펙트를 상상하기 힘들다.
하지만 각 계층의 역할을 이해하고 구조를 고민하면 더 좋은 코드를 작성할 수 있다.
그래서 늘 구조를 설계할 때 신중해야한다.
이번에는 서비스와 컨트롤러 간의 의존성 분리에 대해서 생각해보았다
Spring MVC 패턴
개발에 자주 쓰이는 MVC 패턴은 컨트롤러, 서비스, 레포지토리 이 세가지 계층을 떠올리게 한다.
각 엔티티마다 하나의 컨트롤러, 서비스, 레포지토리를 만들어서 서로 의존하면 참 좋겠지만 그렇지 않다.
최근에 끝낸 프로젝트 BudgetKeemi도 마찬가지다.
예시로 거래 관련 비지니스 로직 처리를 위해서 계정과 카테고리가 필요하다.
이 셋을 연결해 코드를 짜기 위해서
1. 컨트롤러가 여러 서비스에 의존할 것인가
2. 서비스가 서비스끼리 의존할것인가
3. 서비스가 여러 레포지토리에 의존할것인가
이 3가지를 고민해야했다.
장단점
1. 컨트롤러가 여러 서비스에 의존할 것인가
컨트롤러의 역할은 사용자의 요청을 핸들링, 비지니스 로직 호출하는 것이다.
만약 한 컨트롤러가 여러 서비스를 호출한다면 어떻게 될까?
이때 컨트롤러의 역할이 복잡하고 모호해질 수 있다.
또한 테스트를 진행할때도 불편할 수 있다
2. 서비스가 서비스끼리 의존할것인가
가장 일반적인 경우이다.
비지니스 로직이 서비스 안에서 처리되기 때문에 컨트롤러는 더 단순해진다.
그러나 서비스간의 명확한 역할분리가 필요할 수 있다.
3. 서비스가 여러 레포지토리에 의존할것인가
레포지토리는 데이터 접근을 담당한다.
각 서비스가 여러 레포지토리를 직접 사용하는 것은 서비스가 너무 많은 역할을 하게 된다.
나의 생각
나는 일단 레포지토리 계층은 주로 DB의 상호작용하기 때문에 쿼리를 최대한 간단하게 사용하고 싶었다
그래서 3번은.. x
고민 끝에 2번을 선택했다
서비스 계층에 역할이 부담되는 것을 방지하면 코드를 더 깔끔하게 관리할 수 있기 때문이다.
배운 점
자료 조사를 하다가 Facade(퍼사드) 패턴에 대해서 알게 됐다
퍼사드 패턴은 복잡한 클래스를 하나의 간단한 인터페이스로 감싸서 외부에서 단순한 방식으로 사용할 수 있도록 한다.
적용을 고려했지만 BudgetKeemi 자체가 그렇게 복잡한 프로젝트는 아닌 것 같아서 미뤘다..
그래도 이런 고민을 한 덕분에 퍼사드에 대해 자세히 알게 됐다
.