상황

• Controller, Service, Repository로 불리우는 3개의 계층으로 코드 아키텍처 구성 중
• 각각 클라이언트 요청/응답 핸들링, 비즈니스 로직 수행, DAO의 역할을 맡아 관심사를 분리하고, 코드 재사용성을 높이는 등 유연한 구조를 만들기 위해 Spring Boot를 배우면 기본적으로 익히는 내용이다
• 지구멀미에서는 컨트롤러 계층은 서비스 계층의 메서드 한 개를, 서비스 계층은 레포지토리 계층의 메서드 한 개 이상을 조합하여 사용
• 필요에 따라 레포지토리 계층의 로직과는 관련없는, 하나의 서비스 계층 내 메서드들이 공통으로 사용하는 로직을 extract하여 해당 서비스 계층에 정의

문제

• 프로젝트가 조금씩 커져감에 따라 서비스 계층에서 두 가지 문제점이 나타났다

구현 사항이 가득한 메서드의 경우 이해하고 수정하기 어려움

RDB 쿼리 작업과, 그 외의 IO 작업이 동일한 Spring 트랜잭션 내에서 실행되는 코드 (Mixed IO)

Manager 계층 도입

비즈니스 로직

• 우선 막연하게만 생각했던, 서비스 계층에게 맡긴 “비즈니스 로직”이 무엇인지 사례들을 찾아보고 나름대로 고민해보았다
• 비즈니스 로직은 각 팀마다 그 상황에 맞게 정의하고 약속하면 된다고 생각한다
• 나의 경우 서비스 계층의 로직은 그 메서드를 호출하는 컨트롤러의 API가 수행하고자 하는 주 관심사가 어떤 흐름으로 진행되는지 매끄럽게 파악할 수 있는 형태라고 정의했다
  • 큰 틀은 역시 단일 책임 원칙이 맞다
• 따라서 흐름의 이해를 방해할 수 있는, 세부 구현에 집중된 코드는 분리하는 것이 좋겠다고 생각했다

Mixed IO

• 여러 레포지토리 메서드를 조합하여 DB 쓰기 작업을 하는 경우, 데이터 정합성을 위해 서비스 메서드에 @Transactional을 거는 경우가 많다
• 이때 네트워크 연결 등의 다른 IO 작업을 해당 서비스 메서드에서 같이 수행하는 경우, 그 IO 작업의 소요시간만큼 트랜잭션과 DB 커넥션을 낭비하게 된다
  • 이는 곧 내부적으로 컨트롤할 수 없는 외부의 상황으로 인해 DB 커넥션이 부족하여 서비스에 장애가 일어날 여지가 생기는 것
• 이는 다른 IO 작업 메서드(A)와 RDB 쓰기 작업들만 모아놓은 메서드(B)를 분리하여 어딘가에 정의하고 B에만 @Transactional을 적용하면 된다
  • 현재 구조로 해결하기 위해서는
  1. A, B를 서비스에 정의 후 컨트롤러에서 조합
  2. A, B를 레포지토리에 정의 후 서비스에서 조합
• 아니면 너무 많은 작업을 API 하나에 몰아 넣은 것은 아닌지 다시 고민해보는 것도 좋을 수 있겠다