🗻

어질어질 반복 로직 제거하기 (템플릿-콜백 패턴)

생성일

2022/12/10

태그

Spring

Aop

Refactoring

목차

배경

저희 프로젝트의 기능들은 그룹을 기반으로 운영됩니다. 이에 따라 요청한 팀과 멤버의 정보를 대부분의 API 에서 받고 있고 이를 검증하는 로직이 존재합니다. 대부분의 서비스 계층 메서드에서 반복되어 나타나는 해당 검증 로직의 반복을 줄이기 위해 초기에는 클래스 내의 메서드로 분리하는 방식으로 해결해 왔습니다. 하지만 기능들이 점차 추가되면서 서비스 계층이 횡적으로 확장이 되었고, 동일한 검증 로직을 새로운 서비스 계층에서 반복해야 하는 상황이 발생하였습니다. 이때부터 점점 구조 변경의 필요성을 느끼고 있었는데, 쿼리 성능 튜닝을 진행하면서 검증 로직 내 JPA 메서드를 변경하였습니다. 그러자 이 검증 로직 내 JPA 메서드를 이용하던 모든 서비스 계층에서 빨간줄이 그어졌고, 현재 구조는 유지 보수가 힘들다는 것을 깨달아 구조 변경을 결심하였습니다.

문제점

현재 구조가 가지는 문제점은 다음과 같습니다.

전체 서비스 계층에서 공통 로직이 반복된다.

•

모든 서비스에서 같은 로직을 위해 해당 메서드를 사용중입니다. 이에 따라 검증 로직 하나가 바뀌면 4개의 클래스에서 바뀌는 마법…! 테스트쪽 변경은 아직 시작도 안한 상태라는 슬픈 사실,,,

만약 새로운 기능이 추가된다면?

•

검증에 필요한 MemberRepository, TeamRepository, TeamMemberRepository 를 기본적으로 의존하며 동일한 검증 로직을 생성해야 합니다. 또한 새로운 API 마다 검증 로직을 추가해야 하기때문에 실제 비즈니스 로직에 집중할 수 있는 여건이 다소 떨어집니다.

문제를 요약해보면 두 가지 문제를 생각해볼 수 있는데요. 첫째, 검증 로직이 바뀌면 해당 로직을 이용하는 모든 로직에서 수정을 해야 합니다. 예를 들어 사용자를 확인하는 타입이 Long 에서 UUID 와 같은 문자열로 바뀌면 해당 로직을 이용하던 모든 메서드를 찾아 일일이 수정을 해주어야 합니다. 이로 인해 유지, 보수 측면에서 어려움을 겪을 수 있습니다. 둘째, 새로운 API가 추가될 때 검증 로직도 추가해야 한다는 점입니다. 이로 인해 새로운 비즈니스 로직에 대한 집중이 떨어지고 가독성 부분에서도 비효율적이었습니다. 이러한 문제점들을 가지고 있었기때문에 가독성 측면으로나 유지, 보수, 확장의 측면으로나 개선이 필요하다고 생각했습니다.

서비스 계층 설계하기

앞서 언급드렸다시피, 모락 서비스의 모든 기능은 팀을 기반으로 제공됩니다. 이에 따라 모든 API 에는 요청한 팀에 요청한 사용자가 속하는지 확인하는 로직이 존재합니다. 이 과정을 요약하면 다음과 같습니다.

•

interceptor

◦

인터셉터에서는 토큰이 유효한지 검증합니다.

•

resolver

◦

resolver 에서는 받은 토큰을 파싱하여 payload 를 획득하고, controller 의 파라미터에서 요구하는 형태(Long)로 변환하여 전달합니다.

•

controller

◦

path variable 로 받은 team code 와 파라미터로 받은 user id 를 서비스 계층으로 전달합니다.

•

service

◦

서비스 계층에서는 사용자가 요청한 팀에 속하는지 확인한 뒤 비즈니스 로직을 수행합니다.

기존의 서비스 로직은 다음과 같습니다.

// 기존 로직    
@Transactional(readOnly=true)
public List<PollResponse> findPolls(String teamCode, Long memberId) {
        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> MemberNotFoundException.of(CustomErrorCode.MEMBER_NOT_FOUND_ERROR, memberId));
        Team team = teamRepository.findByCode(teamCode)
                .orElseThrow(() -> TeamNotFoundException.ofTeam(CustomErrorCode.TEAM_NOT_FOUND_ERROR, teamCode));
        validateMemberInTeam(team, member);

        List<Poll> polls = pollRepository.findAllByTeam(team);

        return polls.stream()
                .map(poll -> PollResponse.from(poll, member))
                .sorted()
                .collect(Collectors.toList());
    }
Java
복사

기존에는 메서드 첫 다섯 줄은 검증 로직에게 자리를 양보해야 했고, 검증이 끝난 이후에 비로소 비즈니스 로직을 진행할 수 있었습니다. 한 눈에 들어오지 않는 비즈니스 로직이었고, 이러한 반복되는 검증 로직이 전체적으로 반복되어 불편함이 계속 되었던 것입니다.

개선 방향으로는, 현재의 검증 로직이 메서드로 분리(validateMemberInTeam())되어 있는데, 이를 메서드에서 검증 로직 객체 또는 기능으로 한단계 차원을 넓혀보기로 하였습니다. 해결 방법으로 생각해본 방식은 다음 세 가지가 있습니다.

AOP

Spring AOP 를 이용하여, 서비스 계층의 클래스 단위 또는 메서드 단위에 AOP 를 적용하는 것입니다. @Transactional 을 보다가 생각이 난 방식입니다. 그래서 흐름도 @Transactional 과 유사하게 동작하도록 서비스 계층의 메서드가 호출되고 비즈니스 로직이 수행되기 전, 검증 로직을 수행하는 것입니다.

이 방법의 장점으로는 비즈니스 로직에서 검증 로직 코드를 제거할 수 있고, 클래스, 메서드 어디든 설정할 수 있습니다. 또한 어노테이션을 이용해 클래스 혹은 메서드에 해당 로직이 들어간다는 것을 직관적으로 명시할 수 있습니다.

하지만 생각해본 단점으로는 계층간 흐름 방향과 관심사 분리 차원의 문제가 있었습니다.

그림과 같이 계층간 흐름 방향에서 레포지토리 계층을 서비스 계층의 앞에서 한번, 비즈니스 로직에서 또 한번 의존하는 부분은 의존성 흐름의 관점에서 보았을 때 얽혀있다고 판단하였습니다. 또한 AOP 는 공통적으로 부가되는 기능을 묶고 분리하여 비즈니스 로직에 집중 할 수 있도록 모듈화하는 방식입니다. 이러한 관점에서 ‘검증 로직이 우리의 비즈니스 로직과 분리해야하는 관심사인가?’ 라고 생각해 보았을 때, @Transactional 의 관심사인 트랜잭션 획득과는 달리, 검증 로직도 비즈니스 로직 중 일부라고 생각하였습니다. 이에 따라 AOP 방식은 단점이 다소 명확하여 일단 보류하였습니다.

인터셉터 활용

기존 인터셉터에서 수행하던 토큰의 유효성 검증을 확장하여, 멤버가 팀에 속하는지에 대한 검증까지 모두 수행하는 것입니다.

위의 AOP 방식처럼 선수 학습이 필요하지 않아 개발을 빠르게 할 수 있고, AOP 방식과 마찬가지로 비즈니스 로직에서 검증 로직 코드를 제거할 수 있습니다.

하지만 AOP 방식보다 단점이 더욱 명확하였습니다. team code 는 url path 로 확인할 수 있기때문에 url path 문자열에 대한 부가적인 처리 과정이 발생합니다. 또한 home 화면처럼 검증 로직이 수행되지 않는 API 가 있는데, 해당 요청 API가 검증 로직을 수행해야 하는지 HTTP METHOD 와 url path 로 확인해야 하는 번거로움이 있습니다. 이와 함께, 비즈니스 로직에서는 검증 로직이 수행되었다는 것을 직관적으로 나타낼 수 없었습니다. 이에 따라 인터셉터 방식도 보류하였습니다.

새로운 서비스 계층

검증만 전문으로 하는 새로운 서비스 계층을 만들어 검증 로직 은 검증 서비스 계층에서, 이외의 비즈니스 로직은 각각의 서비스 계층에서 수행하는 것입니다. 이 방식은 JdbcTemplate 을 구경하다가 유심히 본 템플릿-콜백 패턴 방식을 차용하였습니다.

public class JdbcTemplate extends JdbcAccessor implements JdbcOperations {

	// ...

	@Nullable
	private <T> T execute(StatementCallback<T> action, boolean closeResources) throws DataAccessException {
		Assert.notNull(action, "Callback object must not be null");

		Connection con = DataSourceUtils.getConnection(obtainDataSource());
		Statement stmt = null;
		try {
			stmt = con.createStatement();
			applyStatementSettings(stmt);
			T result = action.doInStatement(stmt);
			handleWarnings(stmt);
			return result;
		}
		catch (SQLException ex) {
			// Release Connection early, to avoid potential connection pool deadlock
			// in the case when the exception translator hasn't been initialized yet.
			String sql = getSql(action);
			JdbcUtils.closeStatement(stmt);
			stmt = null;
			DataSourceUtils.releaseConnection(con, getDataSource());
			con = null;
			throw translateException("StatementCallback", sql, ex);
		}
		finally {
			if (closeResources) {
				JdbcUtils.closeStatement(stmt);
				DataSourceUtils.releaseConnection(con, getDataSource());
			}
		}
	}
}
Java
복사

JdbcTemplate 의 메서드 중 위의 execute 메서드는 JdbcTemplate 의 다른 메서드인 update, execute, query 등이 호출될 때 항상 호출되는 메서드입니다.

각 update, execute, query 메서드는 StatementCallback<T> 에 맞는 Functional Interface 구현 클래스를 만들고, 위의 execute 메서드는 statement 를 만드는 공통 로직을 수행 후 action.doInStatement(stmt); 을 통해 인자로 받은 메서드를 수행합니다.

위의 execute 메서드와 유사하게, 각각의 서비스는 람다식을 활용하여 비즈니스 로직을 만들고, 검증 서비스(Authorization Service)의 메서드를 호출합니다. 그리고 검증 서비스에서는 공통 로직만 수행 후, 인자로 받은 메서드를 수행하는 구조를 구상하였습니다.

•

JdbcTemplate.execute() == AuthorizationService.authorize()

•

execute() 내부의 createStatement() == 검증 로직

•

action.doInStatement(stmt) == 각각의 비즈니스 로직

으로 생각할 수 있습니다.

이러한 구조를 가지면 검증 로직을 수행한다는 것을 명시할 수 있으면서, 검증 로직은 숨길 수 있습니다. 또한 계층간 흐름 방향도 서비스 계층 단에서 레포지토리 계층 단으로 흐르는 방향으로 구성할 수 있고, 검증 서비스에서는 각각의 서비스를 참조하지 않아 양방향 참조 또한 발생하지 않습니다. 그리고 검증 로직을 하나의 클래스에만 작성하여 응집도를 높일 수도 있습니다. 이에 따라 세 번째 방식인 템플릿-콜백 패턴을 적용한 새로운 서비스 계층을 만들기로 결정하였습니다.

서비스 계층 재설계 적용

서비스 계층에 적용할 구조는 앞서 정리한 그림을 토대로 적용하도록 하겠습니다.

Authorization Service

@Transactional(readOnly=true)
public class AuthorizationService {

    private final TeamRepository teamRepository;
    private final MemberRepository memberRepository;
    private final TeamMemberRepository teamMemberRepository;

    public <R> R withTeamMemberValidation(Supplier<R> supplier, String teamCode, Long memberId) {

        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> MemberNotFoundException.of(CustomErrorCode.MEMBER_NOT_FOUND_ERROR, memberId));

        Team team = teamRepository.findByCode(teamCode)
                .orElseThrow(() -> TeamNotFoundException.ofTeam(CustomErrorCode.TEAM_NOT_FOUND_ERROR, teamCode));

        validateMemberInTeam(team, member);

        return supplier.get();
    }
Java
복사

검증 서비스에서는 팀, 멤버, 팀멤버 레포지토리만 주입받고, 검증과 관련된 로직만 수행합니다. 검증 로직을 수행한 후에는 인자로 들어온 메서드를 실행만 하고, 이외의 비즈니스 로직에는 간섭하지 않도록 하였습니다. 함수형 인터페이스로는 인자 없이 리턴 값만 있는 Supplier 를 사용하였고, 여러 서비스 계층에서 사용할 수 있도록 제네릭을 활용하였습니다. 함수형 인터페이스로 사용되는 다른 인터페이스에 대한 내용은 Functional Interface란 을 참고해주세요!

Poll Service

@Transactional(readOnly=true)
public List<PollResponse> findPolls(String teamCode, Long memberId) {
        return authorizationService.withTeamMemberValidation(
                () -> pollRepository.findAllByTeamCode(teamCode)
                        .stream()
                        .map(poll -> PollResponse.from(memberId, poll))
                        .sorted()
                        .collect(Collectors.toList()), 
												teamCode, 
												memberId
        );
    }
Java
복사

검증 로직을 서비스에서 분리함으로써 각각의 도메인 서비스 계층에서는 비즈니스 로직에 더욱 집중할 수 있게 되었습니다. 서비스 계층에서는 인자로 들어온 teamCode 와 memberId 에 대한 검증을 검증 서비스 계층에 맡기기 위해 메서드의 파라미터로 전달하고, 비즈니스 로직은 람다식으로 구성하였습니다.

결과

검증 로직을 위의 템플릿-콜백 패턴 방식으로 변경하면서 다음과 같은 이점을 가질 수 있었습니다.

가독성 증대

검증을 위해 orElseThrow() 까지 두 줄씩 이어지던 team, member 조회 로직을 제거하고, 검증 서비스의 withTeamMemberValidation 이라는 메서드명으로 검증 로직을 표현할 수 있어 가독성 측면에서 개선이 되었습니다.

비즈니스 로직에 집중

검증 로직은 검증 서비스에 일임하고, 서비스 계층 메서드에서는 콜백 방식의 비즈니스 로직만 있어 비즈니스 로직에만 집중할 수 있었습니다.

횡적으로 모든 도메인 서비스 계층에서 발생하는 검증 로직을 한 곳으로 집중

파라미터 변경 등 검증 로직에 변경이 발생하여도 검증 서비스 내부의 검증 로직에서만 변경이 발생하기때문에 유지보수 등 관리 측면에서도 이점이 있었습니다.