리팩터링할 코드 식별하기

모든 코드는 2차원으로 분류할 수 있다.

• 도메인 유의성(or 복잡도)
• 협력자 수

왼쪽 상단 사분면이 단위 테스트의 가성비가 가장 좋다.

왼쪽 하단 사분면은 테스트할 필요가 없다.

오른쪽 하단 사분면은 통합 테스트로 간단히 테스트해야 한다.

오른쪽 상단 사분면이 제일 문제다.

험블 객체 패턴을 사용해 지나치게 복잡한 코드 분할하기

우리가 테스트하려는 로직이 테스트하기 어려운 의존성과 결합되어 있을 때, 로직을 분리하여 의존성과 결합시켜주는 패턴이다.

험블 객체 패턴은 오케스트레이션을 수행하는 코드에서 복잡한 코드를 분리하도록 설계됐다.

(함수형 아키텍처, 육각형 아키텍처에서도 이러한 분리가 이루어진다)

e.g.1) MVC(Model-View-Controller) 패턴에서 Controller는 험블 객체로 View와 Model을 붙여준다.

e.g.2) DDD에서 집계 패턴(Aggregate Pattern)은 클래스를 묶어서 클래스 간 연결을 줄여준다.

비즈니스 로직의 중간 결과를 기반으로 외부 의존성에 추가 질의가 필요할 때

다음 세 가지 특성의 균형을 고려해서 리팩터링해야 한다.

• 도메인 모델 테스트 유의성: 도메인 클래스의 협력자 수와 유형에 따른 함수
• 컨트롤러 단순성: 의사 결정(분기) 지점이 있는지에 따라 다름
• 성능: 프로세스 외부 의존성에 대한 호출 수로 정리

외부 의존성을 모두 애플리케이션 서비스로 밀어내기

도메인 모델 테스트 유의성이 높고 컨트롤러가 계속 단순하지만 성능이 떨어진다.

도메인 모델에 외부 의존성 주입하기

컨트롤러가 단순하고 성능이 높지만 도메인 모델의 테스트 유의성이 떨어진다.

의사 결정 프로세스 단계를 더 세분화하기

도메인 모델 테스트 유의성이 높고 성능이 좋지만 컨트롤러가 단순하지 않다.

이 문제를 완화할 수 있도록 도와주는 패턴이 있다.

CanExecute/Execute 패턴 사용

e.g.) 개발자 연봉 인상률을 10%로 업데이트한다. 다만 근속년수가 3년 이상인 직원만 해당한다.

→ moreThan3Years 메서드를 만들어서 업데이트 메서드의 앞부분에서 호출한다.

도메인 이벤트를 사용해 도메인 모델 변경 사항 추적

e.g.) 연봉 인상률이 10%로 업데이트된 직원에게 메일을 전송한다.

→ changedManager 객체를 만들어서 비즈니스 로직에서 연봉이 업데이트된 직원에 대해 객체 리스트를 생성한 후, 애플리케이션 서비스에서 해당 객체 리스트를 받아 처리한다.

(업데이트 명령을 내린 후 일괄적으로 메일을 전송할 경우 moreThan3Years 메서드에 걸려 메일을 보내지 말아야할 직원에게까지 메일이 전송된다)