[Clean Architecture 정리] 23장. 프레젠터와 험블 객체

23장. 프레젠터와 험블 객체

프레젠터는 험블 객체(Humble Object) 패턴을 따르는 형태로, 아키텍처 경계를 식별하고 보호하는데 도움을 준다.

 

 

험블 객체 패턴

험블 객체 패턴은 디자인 패턴으로 테스트하기 어려운 행위와 쉬운 행위를 단위 테스트 시에 쉽게 분리할 수 있도록 고안되었다.

기본적인 아이디어는 행위를 두 개의 모듈로 나누고 기본적인 본질을 남긴 뒤, 테스트하기 어려운 행위를 험블 객체로, 테스트 하기 쉬운 행위는 나머지 모듈로 옮기는 것이다.

 

 

프레젠터와 뷰

뷰는 험블 객체이며 테스트하기 어렵다. 뷰는 단순히 데이터를 화면으로 로드할 뿐이다.

프레젠터는 테스트하기 쉬운 객체이다. 프레젠터는 애플리케이션으로부터 전달받은 데이터를 화면에 포맷으로 변환하는 역할을 담당한다.

 

 

테스트와 아키텍처

험블 객체 패턴을 이용하면 테스트가 쉬운 부분과 어려운 부분의 경계를 분리하면 테스트 용이성을 얻을 수 있다.

 

 

데이터베이스와 게이트웨이

유스케이스 인터랙터(usecase interactor)와 데이터베이스 사이에는 데이터베이스 게이트웨이(database gateway)가 위치한다.

데이터베이스 게이트웨이는 다형적 인터페이스로 CRUD와 관련된 모든 메서드를 포함한다.

 

유스케이스 계층은 SQL을 허용하지않기 때문에, 게이트웨이 인터페이스를 호출한다.

인터페이스의 구현체는 데이터베이스 계층에 위치하며 테스트하기 어렵기 때문에 험블 객체이다.

 

반대로 유스케이스 인터랙터는 애플리케이션에 특화된 업무를 캡슐화하기 때문에 험블 객체가 아니다.

게이트웨이를 stub, mock, test-double의 방식으로 처리해 쉽게 테스트할 수 있다.

 

 

데이터 매퍼

ORM은 데이터베이스 계층에 위치하며 게이트웨이 인터페이스와 데이터베이스 사이에서 험블 객체 경계를 형성한다.

 

재밌는 내용

원론적으로 따지면 ORM(Object Relational Mapper)는 존재하지 않는다.

객체는 멤버 변수를 private으로 선언하고 오직 함수많을 통해 제공함으로 오퍼레이션의 집합으로 본다.
public으로 선언된 변수들의 집합은 데이터 구조이다.
ORM은 사실 데이터 매퍼라고 부르는 것이 더 정확하다.

얼마 전, flask API를 만들면서 왜 멤버 변수를 public으로 선언하는 걸까하는 고민을 해본 적이 있다.
외부에서 어떤 데이터가 있는지 알고, 직접 접근하는데 이것이 객체 지향적이라고 할 수 있는걸까라는 생각을 했었는데,
저자는 그러한 의미에서 ORM보다는 Data Mapper가 맞는 표현이라고 생각하는 것 같다.

 

 

서비스 리스너

서비스 경계 또한 험블 객체 패턴을 적용할 수 있다.

외부에서 들어오는 데이터를 서비스 리스너가 서비스 인터페이스로부터 수신하고 애플리케이션에서 사용할 수 있는 데이터 구조로 변환한 다음 서비스 경계를 가로질러 내부로 전달되기 때문이다.

 

 

서적 : http://www.yes24.com/Product/Goods/77283734

클린 아키텍처 - YES24