[🔥TroubleShooting - MoodBuddy🔥] Service 계층이 무겁다면, Facade 패턴 어때?

📌 프로젝트 소개

팀원 : PM(1) / Design(1) / Frontend(2) / Backend(3)
기간 : 2024.03 ~ 2025.03
링크 : https://github.com/M-ung/MoodBuddy_Server
서비스 내용 : 사용자가 작성한 일기를 바탕으로 감정 분석하는 웹 서비스
소통 : GitHub, Slack, Notion, Discord

---

🔥TroubleShooting🔥

Problems

항상 개발을 하면서 드는 고민 중 하나가 Service 계층에 여러 Repository 를 주입해야 할지, 아니면 여러 Service 를 주입해야 할지 고민이 든다.

📍 여러 Repository 주입한 경우

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class DiaryServiceImpl implements DiaryService {
    private final UserRepository userRepository;
    private final ProfileRepository profileRepository;
    private final ProfileImageRepository profileImageRepository;
    private final DiaryRepository diaryRepository;
    private final DiaryImageRepository diaryImageRepository;
    
}

📍 여러 Service 주입한 경우

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class DiaryServiceImpl implements DiaryService {
    private final UserService userService;
    private final ProfileService profileService;
    private final ProfileImageService profileImageService;
    private final DiaryImageService diaryImageService;
    
}

두 가지 방법을 다 적용해 보았지만, "여러 Repository 주입한 경우"는 구현하는 데에 있어서 추가 코드 없이 각 도메인에 Repository 를 통해 접근할 수 있어서 간편했다. 하지만 중복되는 메서드가 각 객체마다 생겨난다는 단점이 있었다.
반대로 "여러 Service 주입한 경우"는 중복되는 코드를 줄일 수 있어서 좋았지만, 코드의 복잡성이 늘어났다.

---

How

결국에는 두 방법 중 어떤 걸 쓰든, 코드를 봤을 때 Service 계층이 너무 무겁게 느껴졌다.

그래서 또 다른 방법은 찾는 도중 "퍼사드 패턴"을 알게 되었다.

퍼사드 패턴이란?
퍼사드 패턴은 복잡한 내부 시스템을 단순화하여 클라이언트가 쉽게 사용할 수 있도록 하는 디자인 패턴이다.

퍼사드 계층을 추가하여 Controller - Facade - Service - Repository 로 구조화하는 것이다.

그래서 위 "퍼사드 패턴" 방식을 적용해 보기로 했다.

---

Process

먼저 큰 틀은 "퍼사드 패턴"을 가져오지만 우리 팀만의 규칙이 추가적으로 필요하다고 생각했다. 그래서 아래와 같은 규칙을 만들었다.

1. 계층 순서는 Controller - Facade - Service - Repository 순으로 유지한다.
2. 하나의 Service 는 최대한 역할에 맞게 하나의 Repository를 갖는다.
3. 하나의 Facade 는 해당 도메인 안에서 여러 Service를 가질 수 있다.

즉 구조는 아래와 같다.

그럼 구조에 맞게 디렉토리 구조와 코드를 작성해 보겠다.

---

Result

문제 해결로 아래와 같은 결과를 얻었다.
1. Service 계층의 메서드 수 14 → 7, 50% 감소.
2. Service 계층의 코드 라인 수 210 → 76, 약 3배 감소.
3. Controller 계층에서 여러 Service를 직접 다루지 않고, 하나의 Facade를 통해 접근 가능.
4. 인터페이스와 구현체 구조로 유연한 확장성 증가.

---

Thoughts

처음으로 퍼사드 패턴을 적용해 프로젝트를 경험해 보았다. 매번 고민이었던 Service 계층에 Service 를 많이 주입할지, Repository 를 많이 주입할지를 이번 기회에 해소할 수 있었다.
퍼사드 패턴을 적용해 각 Service 와 각 Repository 는 각자의 역할을 유지하면서 코드를 깔끔하게 퍼사드 안에 숨길 수 있었다.

나는 개발을 할 때 가장 먼저 고민을 하는 건 '어떻게 해야 깔끔할까?' '어떻게 해야 중복성이 적어질까?' 이다. 하지만 이번 퍼사드 패턴 경험 덕분에 이 고민에 대해 다른 관점을 가질 수 있는 기회가 되었다.

---