[Clean Architecture] 아키텍처 - 험블 객체 (Humble Object)

험블 객체 패턴 (Humble Object Pattern) 이란? 

 

험블 객체 패턴은 디자인 패턴으로,
테스트하기 어려운 행위와 테스트하기 쉬운 행위를
단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안되었다.

 

• 테스트가 어려운 행위들을 단위테스트가 쉬운 행위, 테스트가 어려운 행위 두가지 모듈 또는 클래스로 나누는 것이다.
• 테스트가 어려운 모듈이 험블 객체 부분이다.
• 테스트의 용이성은 아키텍처에 중요한 요소인데, 험블 객체 패턴이 좋은 예이다.

 

험블 객체 패턴의 예시들

 

1) 프레젠터와 뷰

• 뷰 : 험블 객체이고 테스트하기 어렵다. 
  - 뷰 객체에 포함된 코드는 가능한 한 간단하게 유지.
  - 뷰는 데이터를 GUI로 이동시키지만, 데이터를 직접 처리하지는 않는다.
• 프레젠터 : 테스트하기 쉬운 객체이다.
  - 프리젠터의 역할은 애플리케이션으로부터 데이터를 받아 화면에 표현할 수 있는 포맷으로 만드는 것.
  - 이를 통해 뷰는 데이터를 화면으로 전달하는 간단한 일만 처리하도록 한다.
• case - 애플리케이션에서 어떤 필드에 날짜를 표시하고자 하는 경우.
  
  • 프레젠터 : 날짜 데이터를 적절한 포맷의 문자열로 만들고, View Model이라는 간단한 데이터 구조에 담는다.
  • 뷰 : View Model에서 이 데이터를 찾는다. 
• case - 특정 버튼을 비활성화 해야한다면?
  • 프레젠터는 뷰 모델에서 적절한 불 타입 플래그를 설정한다.

2) 유스케이스 인터랙터와 데이터베이스

• 유스케이스 인터랙터와 데이터베이스 사이에는 Database Gateway가 위치한다.
  - 이는 다형적 인터페이스로, 애플리케이션이 데이터베이스에 수행하는 생성, 조회, 갱신, 삭제 작업과 관련된 모든 메서드를 포함.
  - 유스케이스 계층은 SQL을 허용하지 않으므로 Database Gateway를 데이터베이스와 경계로 두고있음.
• 데이터베이스 : 험블 객체
  - Database Gateway의 구현체이며 직접 SQL을 사용하거나 임의의 인터페이스를 통해 게이트웨이 메서드에 필요한 데이터에 접근한다.
  - 데이터를 직접 핸들링하기 때문에 테스트가 어렵다.
  (Transaction에 대한 테스트가 불가능한 것은 아니라 공감은 안되지만 어쨌든 데이터변경의 위험이 있기때문에 테스트가 어렵다는 말이 틀리다고 할 수 는 없을 것 같다.)
  - 참고) Data mapper의 역할을 해주는 하이버네이트같은 ORM은 Database Gateway와 데이터베이스 사이의 또다른 험블 객체의 역할을 한다.
• 유스케이스 : 업무규칙이 캡슐화 되어있으므로 테스트하기 쉬움.
  - 진짜 데이터베이스 객체(Gateway 구현체)를 테스트 더블(stub, mock 등)로 적당히 교체할 수 있기 때문.

3) 서비스 리스너

• 어플리케이션이 다른 서비스와 반드시 통신해야하는 케이스에서도 험블 객체 패턴을 발견할 수 있음.
• 통신에 알맞는 데이터 포맷으로 바꾸는 모듈 : 테스트하기 쉬운 객체
  - 데이터를 수신하는 경우 : 데이터를 받은 후, 어플리케이션에 적합한 포맷으로 데이터 핸들링.
  - 데이터를 송신하는 경우 : 송신에 적합한 간단한 데이터 구조로 데이터 핸들링.
• 데이터를 송/수신하는 역할을 하는 모듈 : 험블 객체이다.
  - 데이터를 송/수신하는 역할.

 

결론

험블 객체 패턴을 통해 전체 시스템의 테스트 용이성을 크게 높일 수 있다.