지금어디' 프로젝트가 끝난 이후 서비스 개선 및 유지보수 작업에 들어가고 있었습니다.
그러나 버전업을 시키는 과정에서 단일 모듈에서 개발한 코드들의 문제점을 발견하여 아키텍처를 개선하기 위해 조사를 하던 중 멀티 모듈의 존재에 대해 알게 되었습니다.
개발하면서 가장 크게 느낀 문제는 객체지향적이지 못한 코드로 인해 발생한 문제들이었습니다.
크게 2가지의 문제점이 있었는데
- 비대해진 서비스 클래스
- 서비스가 영속성 계층에 영향을 받는다
서버는 저 포함 2명의 팀원이 각자 매주 특정 기능을 구현하고 버그를 고치는 방식으로 개발되었습니다. 저희가 만드는 서비스는 작은 규모여서 각자가 특정 도메인을 나눠서 개발하기보다는 하나의 도메인 안에서 작은 기능들을 분담하여 개발하는 경우가 많았습니다.
그러나 더 큰 문제는 하나의 서비스 객체에 모든 비즈니스 로직을 넣어서 개발한 것입니다. 각자의 책임과 역할을 나눠 객체를 개발하고 합치는 방식이 아니라, 하나의 클래스 안에서 모든 것을 해결하려다 보니 각자의 브랜치에서 작업한 코드가 합쳐질 때 중복이 발생하고, 여러 문제가 생겼습니다. 비대해진 클래스 코드와 그에 따른 분석의 어려움도 큰 문제였습니다.
이러한 상황이 반복되자, 한 사람이 개발을 완료할 때까지 다른 사람들이 기다려야 하는 불편한 상황이 되었습니다.
**컨트롤러 - 서비스 - 리포지토리 패턴(기존 SERVER 아키텍)**에서는 컨트롤러가 서비스를, 서비스가 리포지토리를 의존하는 특정 방향으로 개발됩니다.
public class ScheduleService {
private final MembeRepository memberRepository;
private Member returnMember(String memberId) {
return memberRepository.findById(memberId)
.orElseThrow(() -> new UserNotFoundException(USER_NOT_FOUND_EXCEPTION_MESSAGE));
}
... // 서비스 코드에서 레포지토리 코드를 의존하고 있음
}
위의 코드는 이번 작업의 일부입니다. 의존성이란 A를 생성하고 사용할 때 B를 알지 못하면 동작이 불가능한 것을 의미합니다.
즉, 서비스 코드에서는 영속성 계층의 리포지토리 코드를 알아야 동작합니다.
물론 서비스 코드가 비즈니스 로직을 수행하기 위해 영속성 계층의 코드를 사용해야 하는 것은 맞습니다. 그러나 서비스 객체가 리포지토리 객체를 의존하게 되면, 리포지토리의 메서드나 로직이 변경될 때 서비스 코드도 수정해야 합니다.
리포지토리의 코드 변경이 서비스의 코드를 변경하게 만들고, 이는 유지보수 과정에서 복잡한 로직에도 영향을 미쳐 시간이 흐를수록 수정에 많은 자원이 필요하게 됩니다.
모듈화의 목표는 기존에 뒤섞여 있는 계층형 코드를 분리하여 관리 용이성을 높이는 것입니다.
따라서 기존 코드를 다음과 같이 네 가지 모듈로 분리할 예정입니다:
1. 컨트롤러단을 위한 모듈 - applicatoin
2. 서비스(비즈니스 도메인)을 위한 모듈 - domain(usecase)
3. 레포지토리(영속성 계층)을 위한 모듈 - data
4. Global Config를 위한 모듈 - core