https://jangjjolkit.tistory.com/62

현재 개인적으로 위 블로그에서, 2번은 이미 해본 방법이다.

하지만 현재 내 경험은

  1. Service에서 간단한 CRUD를 처리하고, 타 Repo에 필요한 기능은 해당 Service에서 꺼내와서 사용한다.
    1. 이는 내가 경험이 없었기에, Service끼리 순환 호출 될 경우, 안된다는 사실을 몰랐기에, 위와 같은 방식을 사용했었다.
  2. Service에서 최대한 타 Service 호출을 자제한다.
    1. 하지만 프로젝트가 복잡해질수록, 서로 사용하는 로직이 겹치는 서비스가 생겨나기 시작. 동시에 타 서버와의 데이터 동기화 부분은 Service로 관리해야하는 부분이기에, 해당 부분에서 순환호출이 빈번하게 일어남.
    2. 일단 Chat service 부분의 순환호출을 유발하는 Chat 서버와의 동기 부분을 별도의 API 호출용 tool처럼 구분하면 어떻까? Service보다는 Util? 느낌으..

위 경험들에서 깨달은 것은.

절대로 Entity 기준에서 Service를 작성하면 안된다.

Service는 Controller 기준에서 필요한 기능을 만드는 것이다.

그리고 마지막으로 블로그에서 3번째로 소개시키는 서비스의 레이어를 나누는것.

설계가 많이 힘들 것이지만, 체계적으로 구분 된다면 괜찮은 방법이라고 생각한다.

불필요한 중복 메서드를 많이 줄일 수 있을 것이다.