[TIL] 도메인 기반 3-Tier 구조에서 SRP 고민(feat. Facade 개념 적용)

< 목차 >
1. 트랜잭션에 대한 문제
2. 다른 Service를 묶는 Service 생성
3. 왜 Facade인가?
4. 마무리

 

개요

지난 번 3-Tier 구조에서 필연적으로 발생하는 단일 책임 원칙(Single Responsibility Principle, SRP) 위배에 대해 글을 작성했다. 당시에는 트랜잭션 고려에 큰 비중을 두지 않았다. 하지만, 프로젝트를 진행하며 트랜잭션이 문제가 되었다. 해당 문제에 대해 나는 ServiceFacade라는 클래스를 생성했다. Facade 단어의 개념적 내용을 적용했다. 해당 글에서는 내가 왜 이렇게 결정내리게 되었는지 그 과정과 내 생각을 기술하고자 한다.

 

 1. 트랜잭션에 대한 문제 

지난 블로그에서 나는 Controller에서 다른 도메인 Service를 참조해서 사용하기로 결정했다. 하지만, 하나의 Controller에서 서로 다른 도메인 Service끼리 묶여 있으니 트랜잭션에 대해 어떻게 관리해야 할지 고민하게 되었다.

다음과 같은 흐름에서 고민을 하게 되었다. 현재 상황은 A 도메인 Service와 B 도메인 Service가 있다.

1. A 도메인 Service에서 A의 정보 존재여부 확인
2. B 도메인 Service에서 A의 외래키를 가진 정보 추가

1, 2번 사이에서 A의 정보가 삭제된다면 트랜잭션이 필요하지 않을까 생각이 들었다.

이 상황을 코드로 작성했던 게 아래의 사진이다.

 

// 내가 작성한 이전 관련 블로그

2025.02.16 - [🌃 TIL] - [TIL] 3계층 구조의 단일 책임 원칙(SRP) 위배

 

 2. 다른 Service를 묶는 Service 생성

내가 고안해낸 방식은 다음과 같다. 현재 도메인을 A 도메인이라고 가정하고 나는 B 도메인의 Service를 사용하고 싶은 상태이다.

• A 도메인 Service Package
  • A handler? Service
  • A Service
  • BA Service

여기서 A Service는 현재 도메인의 Service고 BA Service는 B 도메인의 Service를 사용하기 위해 A 도메인에 추가로 생성한 상태이다. 이제 A Service와 BA Service를 함께 묶어 트랜잭션을 관리하기 위한 Service가 A handler Service이다. 어떻게 이름을 지어줘야 할지 몰라서 나의 친구 GPT에게 네이밍 추천을 받았다.

 

 3. 왜 Facade인가? 

내가 생각했던 방식을 주변 멘토분께 여쭤보았다. 멘토분은 hadnler 대신 Facade 패턴을 찾아보면 도움이 될 거라는 답변을 해주셨다.

퍼사드 패턴(Facade Pattern)은 구조 패턴(Structural Pattern)의 한 종류로써, 복잡한 클래스들의 공통적인 기능을 정의하는 상위 수준의 인터페이스를 제공하는 패턴이다.

 

실제로 Facade 패턴을 적용한 것은 아니지만, 여러 Service를 한 곳에서 관리하고 트랜잭션을 다루는 개념이 Facade의 역할과 비슷하다고 생각했다. 그래서 이름을 {도메인}Facade로 지었다.

 

아래는 내가 만든 패키지 구조이다.

 

실제 내가 생각한 구조를 적용한 Controller와 FavoriteFacade의 코드다.

FavoriteFacade에서 드디어 트랜잭션을 하나로 관리할 수 있게 되었다.

 

 4. 마무리

객체지향 설계원칙(SOLID) 중에서 SRP 원칙을 위배하지 않기 위해 고민하는 과정은 나에게 새로운 영감을 주었다. 실제로 패턴을 적용한 것은 아니지만, 네이밍에서 Facade의 역할을 차용함으로써 코드의 명확성과 일관성을 높일 수 있었다. 이 과정에서 다른 설계 방식도 고려하기 위해서는 디자인 패턴이 중요하다는 걸 깨달았다.