[항해 플러스 Lite 백엔드] 3주차 WIL #클린아키텍처 #레이어드아키텍처

과제

이번 주 과제는 콘서트 예약 서비스의 비즈니스 로직 개발과 단위 테스트 작성이었다.

특히, 예약/결제 기능은 클린 아키텍처로, 나머지 기능은 레이어드 아키텍처로 구현하는 것이 과제의 핵심 조건이었다.

 

 

과제 해결 과정

📎 과제 PR 링크

 

패키지 구조 구성

과제를 시작하며 가장 먼저 고민한 것은 패키지 구조를 어떻게 구성할 것인지였다.

초기에 고려했던 방식은 두 가지였다

 

1. 계층(레이어) 중심 패키지 구성

controller, service, repository 등 기능의 역할을 기준으로 디렉토리를 나눈 뒤, 그 안에서 도메인 단위로 분리하는 방식이다.

controller
  └─ user
  └─ concert
service
  └─ user
  └─ concert
repository
  └─ user
  └─ concert

 

 

2. 도메인 중심 패키지 구성

도메인(비즈니스 단위) 별로 디렉토리를 나누고, 그 안에 controller, service, repository를 포함하는 방식이다.

user
  └─ controller
  └─ service
  └─ repository
concert
  └─ controller
  └─ service
  └─ repository

 

 

고민 끝에 도메인 중심 구조를 선택했다.
그 이유는 예약/결제 기능을 클린 아키텍처로 구현해야 했기 때문인데,
초반에는 클린 아키텍처에 대한 이해가 부족해 구조를 어떻게 잡아야 할지 감이 잡히지 않았다.
그래서 먼저 전체 기능을 도메인 중심 + 레이어드 아키텍처 방식으로 개발하고,
그 후 예약/결제 기능만 클린 아키텍처 구조로 리팩토링하는 전략을 선택했다.

 

 

기능 개발 단위 테스트 작성

 

마일스톤을 기반으로 각 기능별 요구사항과 순서를 정리한 후, 일정에 맞춰 기능 개발과 단위 테스트를 병행하며 진행했다.

우선 모든 기능을 레이어드 아키텍처로 먼저 구현했고,
이후 클린 아키텍처 구조로 전환이 필요한 예약/결제 기능에 대해서는 다음과 같이 리팩토링을 진행했다.

 

 

 

# 기존 DDD 패키지 구조

 

# 클린 아키텍처 리팩토링 후 구조

 

 

기존에는 controller, service, repository 중심의 전형적인 구조를 사용했으나,

리팩토링 후에는 application, domain, interfaces, infrastructure 계층으로 나누어 클린 아키텍처의 흐름에 맞게 구조화했다.

이 과정에서 기능별 책임이 더 명확해졌고, 테스트 코드 역시 유즈케이스 중심으로 작성하기 쉬워졌다.

 

회고

이번 주는 시간적으로 꽤 빠듯했다.
클린 아키텍처에 대한 이해 부족과 구조 설계에 대한 고민으로 초반에 많은 시간을 소모했고,
그로 인해 대기열 관리 기능과 controller/repository 레이어의 테스트 코드는 아직 작성하지 못했다.

아직은 익숙하지 않지만, 앞으로 더 많은 코드를 클린 아키텍처 기반으로 작성해보며 점차 익숙해지는 것이 목표다.
다음 주에는 예정된 과제와 함께 미완성된 테스트 코드 및 대기열 기능도 마무리할 계획이다.