아키텍처 - 프레젠터와 험블객체

- 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.)

- 험블 객체: https://martinfowler.com/bliki/HumbleObject.html

- 험블 객체 패턴

프레젠터는 험블 객체 패턴을 따른다. 험블(humble)이란 사전적으로 보잘것없다는 의미를 지니고 있다. 험블 객체 패턴은 디자인 패턴으로 테스트하기 어려운 행위와 쉬운 행위를 분리하는 패턴이다.

 

뷰와 엮인 경우 테스트 하기 어려운 부분이 존재하는데, 테스트하기 쉬운 영역과 어려운 영역으로 나누면 프레젠터와 뷰라는 클래스로 나뉘게 된다.

---

- 프레젠터와 뷰

사전적인 의미로 생각해보면 프레젠터와 뷰는 비슷한 느낌이 든다. 하지만 설계 관점에서 이 두 가지를 구분한다. 뷰는 험블 객체이며, 테스트하기가 어렵다. 반면 프레젠터는 테스트하기 쉬운 객체다. 무엇이 달라서 테스트하기 쉽고 어렵다고 하는걸까? 테스트의 난이도에 따라 왜 구분할까?

 

만약 화면에 날짜나 시간을 보여주고 싶다고 가정하자. DB에 timestamp나 Java의 Date 객체를 뷰에 그대로 표시되도록 개발하지는 않을 것이다. 아마 적절한 날짜 포맷이나 시간 포맷으로 변환할것이다. 

 

프레젠터는 어플리케이션으로 부터 데이터를 받아 화면에 표시하도록 특정 포맷의 문자열로 변환한다. 이를 뷰-모델에 담으면 뷰는 뷰-모델에서 이 데이터를 찾는다. 뷰는 뷰-모델을 그대로 화면으로 불러오며, 특별한 역할이 없다. 따라서 뷰는 보잘것없는(험블 - humble) 객체이다.

---

- 테스트와 아키텍처

아키텍처를 테스트 관점에서 보면 좋은 아키텍처는 테스트하기가 수월해야 한다. 앞서 말했듯이 험블 객체 패턴은 테스트의 난이도에 따라 분리하며, 이는 곧 아키텍처의 경계가 된다.

 

앞서 이런 방식으로 도출해낸 프레젠터와 뷰도 이런 경계중에 하나인것이다.

---

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

유스케이스와 데이터베이스 사이에는 게이트웨이가 있다. 나를 포함하여 이 용어에 익숙하지 않고, 한국의 전형적인 스프링 CRUD의 K-노예라면 서비스 - Dao 인터페이스 - Dao 라고 생각하면 이해가 편하다.

 

게이트웨이는 CRUD와 관련된 메소드 시그니처들이 있다. 유스케이스 계층에서는 SQL을 사용하면 안된다. 유스케이스는 게이트웨이 인터페이스를 통해서 호출하고, 데이터베이스 계층인 게이트웨이 구현체에서 데이터를 로드한다.

 

여기서 게이트웨이 구현체는 험블객체이며 인터랙터는 험블객체가 아니다. 만약 JUnit 테스트를 작성할때, Service 메소드에 대한 테스트를 작성해야 한다면 DB에서 직접 데이터를 로드하는 방식이 아닌 Stub을 통해 데이터를 작성해야 한다. DB를 통해 직접 테스트하는것은 다른사람과 해당 데이터에 대해 동시 접근 및 수정할 경우 문제가 있을 수 있고, 계층을 분리하여 테스트를 용이하게 설계한 의도 자체를 무시하는행위이다.

---

- 결론

각 아키텍처 경계에는 험블 객체 패턴이 있다. 경계간에는 간단한 데이터구조로 통신한다. 이 때 험블 객체 패턴을 이용하여 테스트하기 쉽고 어려운것으로 분리하면 테스트가 보다 쉬워진다.