단위테스트 책에서 단일책임원칙을 적용하는 사례로 비지니스 로직과 오케스트레이션 역할을 분리하는 케이스를 설명해 준다. 오케스트레이션 이란 비지니스 로직을 수행하면서 협력하는 객체들과 커뮤니케이션하는 역할을 하는 코드를 말한다.
비지니스 로직에서 의존 객체들과의 커뮤니케이션하는 코드를 완전히 분리해서 별도의 객체가 수행하도록 하고 비지니스로직을 담은 객체는 순수함수가 되게 한다. 즉 어떤 입력에 대해 항상 동일한 출력을 보장하며, 어떠한 부수효과도 가지지 않는다. 이걸 Humble 객체 패턴이라고 소개한다.
이렇게 하면 핵심 비지니스 로직에 대한 테스트 코드를 작성하고 유지보수하기 쉬워진다. 실행 성능도 좋아지며 중요한 비지니스 로직에 대한 단위 테스트를 집중할 수 있게 된다.
지난 장에는 저자가 모든 로직을 순수함수가 되게 할 수는 없으며 때때로 어떤 로직은 순수함수로 만들기 위해 성능을 포기해야하는 케이스도 있다고 균형있게 설명해 주었다. 어쨋든 만능은 아니고 검토하고 판단해야 할 트레이드오프가 존재한다.
Humble객체 패턴을 설명하며 헥사고날 아키텍처와 함수형 아키텍처도 그 뿌리를 함께 하는 원리임을 설명해 준다.
헥사고날 아키텍처는 비지니스 로직을 담은 도메인 계층과 외부 의존성과의 상호작용을 담당하는 애플리케이션 서비스 계층을 분리한다. 반면 함수형 아키텍처는 한 걸음 더 나아가 모든 부수효과를 일이키는 내부 객체와의 상호작용 마저 분리한다.
테스트 코드를 중심으로 이런 디자인 패턴들을 설명해 주니 그 어떤 책 보다 실감나게 와닿는다. 객체지향 언어인 자바에서도 이런 특징들을 잘 활용해야 겠다고 느낀다.
