[만들면서 배우는 클린 아키텍처] 08. 경계 간 매핑하기

서론

각 계층의 모델을 매핑하는 전략에 대해 살펴본다.

이미지 출처 : https://rudaks.tistory.com

---

‘매핑하지 않기’ 전략

• 모든 계층이 동일한 모델을 사용하는 매핑 전략이다.
• 문제점
  • 도메인 모델에서 비즈니스가 아닌 웹이나 영속성과 관련된 특수한 요구사항을 모두 다뤄야 한다.
  • 단일 책임 원칙을 위반한다 (변경해야 할 이유가 많아진다).
  • 각 계층이 도메인 모델에 특정 커스텀 필드를 두도록 요구한다면, 오로지 한 계층에서만 필요한 필드들을 포함하는 파편화된 도메인 모델로 이어질 수 있다.
• 모든 계층이 정확히 같은 구조의, 정확히 같은 정보를 필요로 한다면 ‘매핑하지 않기’ 전략은 완벽한 선택지다.
• 하지만 애플리케이션 계층이나 도메인 계층에서 웹과 영속성 문제를 다루게 되면 곧바로 다른 전략을 취해야 한다.

양방향 매핑 전략

• 각 계층마다 전용 모델을 가지는 매핑 전략이다
• 장점
  • ‘매핑하지 않기’ 전략 다음으로 간단한 전략이다
  • 각 계층이 전용 모델을 가지고 있는 덕분에 각 계층이 전용 모델을 변경하더라도 다른 계층에는 영향이 없다
  • 각 계층은 자신이 다루는 문제에 특화된 도메인 모델을 가진다
  • 단일 책임 원칙을 만족하여, 웹이나 영속성 관심사로 오염되지 않은 깨끗한 도메인 모델로 이어진다
• 단점
  • 너무 많은 보일러 플레이트 코드가 생긴다
  • 도메인 모델이 계층 경계를 넘어서 통신하는데 사용되어, 바깥쪽 계층의 요구에 따른 변경에 취약해진다.
• 양방향 매핑 전략은 신선한 법칙으로 여겨지고는 하는데, 이 또한 절대 silver bullet이 아니다.

완전 매핑 전략

• 각 연산마다 별도의 입출력 모델을 사용하는 매핑 전략이다.
• 이 매핑 전략을 전역 패턴으로 추천하지는 않는다.
• 이 전략은 웹 계층(혹은 인커밍 어댑터)과 애플리케이션 계층 사이에서 상태 변경 유스케이스의 경계를 명확하게 할 때 가장 빛을 발한다.
• 애플리케이션 계층과 영속성 계층 사이에서는 매핑 오버헤드 때문에 사용하지 않는 것이 좋다.

단방향 매핑 전략

• 모든 계층의 모델들이 동일한 인터페이스를 구현하는 매핑 전략이다.
• 이 인터페이스는 관련 있는 특성에 대한 getter 메서드를 제공하여 도메인 모델의 상태를 캡슐화한다.
• 상태를 변경하는 것이 인터페이스에 의해 노출되어 있지 않기에, 실수로 도메인 객체의 상태를 변경하는 일이 발생하지 않는다.
• 도메인 모델 자체는 풍부한 행동을 구현할 수 있고, 애플리케이션 계층 내의 서비스에서 이러한 행동에 접근할 수 있다.
• 바깥 계층에서는 상태 인터페이스를 이용할지, 전용 모델로 매핑해야 할 지 선택할 수 있다.
• 애플리케이션 계층에서는 바깥 계층에서 전달하는 객체를 실제 도메인 모델로 매핑해서 도메인 모델의 행동에 접근할 수 있다.
• 이 매핑은 팩터리라는 DDD 개념과 잘 어울린다.
  • 팩터리는 어떤 특정한 상태로부터 도메인 객체를 재구성할 책임을 가지고 있다.
• 이 전략에서 매핑 책임은 명확하다.
  • 한 계층이 다른 계층으로부터 객체를 받으면 해당 계층에서 이용할 수 있도록 다른 무언가로 매핑한다.
• 이 전략은 계층 간의 모델이 비슷할 때 가장 효과적이다.
  • 예를 들어, 읽기 전용 연산의 경우 상태 인터페이스가 필요한 모든 정보를 제공하기 때문에 웹 계층에서 전용 모델로 매핑할 필요가 전혀 없다.

언제 어떤 매핑 전략을 사용할 것인가

• 한 마디로, ‘그때그때 다르다’
• 각 매핑 전략이 장단점을 갖고 있기 때문에 한 전략을 전체 코드에 동일하게 적용하면 안된다.
• 팀 내에서 합의할 수 있는 가이드라인을 정해둬야 한다.
  • 이 가이드라인은 어떤 상황에서 어떤 매핑 전략을 가장 먼저 택해야 하는지 설명해야 한다
  • 또한, 왜 해당 전략을 최우선으로 택해야 하는지 설명할 수 있어야 한다.
    그래야 그러한 근거들이 시간이 흐른 후에도 여전히 유효한지 평가할 수 있기 때문이다.

정리

• 인커밍/아웃고잉 포트는 서로 다른 계층이 어떻게 통신해야 하는지를 정의한다. 계층 사이의 매핑 전략이 여기에 포함된다.
• 각 유스케이스에 대해 좁은 포트를 사용하면 다른 유스케이스에 영향을 주지 않고 코드를 개선할 수 있고, 유스케이스마다 다른 매핑 전략을 사용할 수 있기 때문에 특정 상황에 맞는 최선의 전략을 선택할 수 있다.
• 저자의 조언