Clean Architecture 정리 - 5부 23장 프레젠터와 험블객체

험블 객체 패턴 (Humble Object Pattern)

• 정의
  테스트하기 어려운 코드와 테스트하기 쉬운 코드를 분리하여 단위 테스트 작성이 쉽도록 하는 디자인 패턴임.
  GUI, 네트워크, 입출력 등 테스트가 어려운 행위를 분리하여 다른 객체로 위임함.
• 핵심 개념
  아키텍처 경계를 넘는 시점에는 테스트가 어려운 무언가(예: UI, 네트워크, DB)가 존재함.
  험블 객체 패턴은 이 경계 근처에 존재하는 테스트 어려운 부분과,
  테스트 가능한 부분을 분리하여 테스트 용이성을 높이기 위한 전략으로 사용할 수 있음.

---

프레젠터와 뷰

• 경계: 유스케이스 → 시스템 (출력)
• 프레젠터(Presenter): 유스케이스의 출력을 뷰 모델로 변환
  테스트 용이 → 일반 객체
• 뷰(View): 사용자에게 데이터를 보여주는 컴포넌트
  테스트 어려움 (렌더링, 시각 요소 등) → 험블 객체
• 흐름 요약:
  1. 유스케이스에서 전달받은 도메인 값을 사람이 읽기 쉬운 형식으로 가공
  2. 예: 날짜 '2025년 12월 25일', 금액 '₩10,000', isNegative: true 등
  3. 프레젠터는 이 데이터를 뷰모델로 만들어 뷰에 전달
  4. 뷰는 이를 화면에 표시함

---

데이터베이스 게이트웨이

• 경계: 유스케이스 → DB (명령/조회)
• 게이트웨이 인터페이스를 활용하는 유스케이스 인터렉처
  테스트에서는 mock/stub 등 게이트웨이 구현체를 대체하여 테스트 용이 → 일반 객체
• 게이트웨이 구현체
  SQL/ORM을 활용해 실제 DB와 통신 → 테스트 어려움 → 험블 객체
• 흐름 요약:
  1. 유스케이스 인터렉터는 게이트웨이 인터페이스를 통해 필요한 데이터를 요청함
  2. 게이트웨이 구현체는 ORM 또는 SQL을 이용해 DB에서 데이터를 조회하여 반환하거나 저장함

추가: ORM

• ORM은 게이트웨이 구현체 안에서 사용됨 → 데이터베이스 계층에 속함

---

서비스 리스너

• 경계: 외부 서비스 → 애플리케이션 (이벤트 수신)
• 리스너: 외부 요청(메시지, API 호출 등)을 수신하고 내부로 전달
  네트워크 I/O 포함 → 테스트 어려움 → 험블 객체
• 데이터 변환 로직: 수신된 데이터를 내부 포맷(DTO 등)으로 변환
  테스트 용이 → 일반 객체
• 흐름 요약:
  1. 리스너가 외부 요청을 수신함
  2. 수신된 JSON/메시지를 내부에서 사용할 수 있도록 구조화함
  3. 구조화된 데이터를 유스케이스에 전달함

 

※ 본 글은 『Clean Architecture』(로버트 C. 마틴 저) 5부 23장을 기반으로 학습 목적으로 요약한 글입니다.

※ 이 글은 책의 내용을 요약한 것으로, 원문 없이 읽을 경우 오해의 여지가 있을 수 있습니다. 정확한 이해를 위해 원서의 정독을 권장합니다.