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

8. 경계 간 매핑하기

“매핑하지 않기” 전략

장점

• CRUD와 같은 단순 작업에서는 좋다.
• 모든 계층이 정확히 같은 구조의, 정확히 같은 정보를 필요로 한다면 완벽한 선택지이다.

문제점

• 웹, 애플리케이션, 영속성 계층과 관련된 이유로 인해 변경돼야 하기 때문에 단일 책임 원칙을 위반한다.
• 각 계층이 특정 커스텀 필드를 두도록 요구할 수 있다. 그 결과, 오로지 한 계층에서만 필요한 필드들을 포함하는 파편화된 도메인 모델로 이어질 수 있다.

“양방향” 매핑 전략

장점

• 각 계층이 전용 모델을 가지고 있는 덕분에 각 계층이 전용 모델을 변경하더라도 다른 계층에 영향이 없다.
• 그래서 웹 모델은 데이터를 최적으로 표현할 수 있는 구조를 가질 수 있고, 도메인 모델은 유스케이스를 제일 잘 구현할 수 있는 구조를 가질 수 있다.

단점

• 너무 많은 보일러플레이트 코드가 생긴다.
• 도메인 모델이 계층 경계를 넘어서 통신하는 데 사용되고 있다.

“완전” 매핑 전략

• 각 연산이 전용 모델을 필요로 하기 떄문에 웹 어댑터와 애플리케이션 계층 각각이 자신의 전용 모델을 각 연산을 실행하는 데 필요한 모델로 매핑한다.
• 한 계층을 다른 여러 개의 커맨드로 매핑하는 데는 하나의 웹 모델과 도메인 모델 간의 매핑보다 더 많은 코드가 필요하다. 하지만 이렇게 매핑하면 여러 유스케이스의 요구사항을 함께 다뤄야 하는 매핑에 비해 구현하고 유지보수하기가 훨씬 쉽다.
• 이 매핑 전략을 전역 패턴으로 추천하지는 않는다. 이 전략은 웹 계층(혹은 인커밍 어댑터 종류 중 아무거나)과 애플리케이션 계층 사이에서 상태 변경 유스케이스의 경계를 명확하게 할 때 가장 빛을 발한다. 애플리케이션 계층과 영속성 계층 사이에서는 매핑 오버헤드 때문에 사용하지 않는 것이 좋다.

“단방향” 매핑 전략

• 동일한 상태 인터페이스를 구현하는 도메인 모델과 어댑터 모델을 이용하면 각 계층은 다른 계층으로부터 온 객체를 단방향으로 매핑하기만 하면 된다.
• 이 매핑은 팩터리라는 DDD 개념과 잘 어울린다. DDD 용어인 팩터리는 어떤 특정한 상태로부터 도메인 객체를 재공성할 책임을 가지고 있다.
• 계층 간의 모델이 비슷할 때 가장 효과적이다.

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

• 그때그때 다르다.

• 각 매핑 전략이 저마다 장단점을 가지고 있기 때문에 한 전략을 전체 코드에 대한 어떤 경우에도 변하지 않는 전역 규칙으로 정의하려는 충동을 이겨내야 한다.

• 변경 유스케이스를 작업하고 있다면 웹 계층과 애플리케이션 계층 사이에서는 유스케이스간의 결합을 제거하기 위해 ‘완전 매핑’ 전략을 첫 번째 선택지로 선택해야 한다. 이렇게 하면 유스케이스별 유효성 검증 규칙이 명확해지고 특정 유스케이스에서 필요하지 않은 필드를 다루지 않아도 된다.

• 변경 유스케이스를 작업하고 있다면 애플리케이션과 영속성 계층 사이에서는 매핑 오버헤드를 줄이고 빠르게 코드를 짜기 위해서 매핑하지 않기 전략을 첫 번째 선택지로 둔다. 하지만 애플리케이션 계층에서 영속성 문제를 다뤄야 하게 되면 ‘양방향’ 매핑 전략으로 바꿔서 영속성 문제를 영속성 계층에 가둘 수 있게 한다.

• 쿼리 작업을 한다면 매핑 오버헤드를 줄이고 빠르게 코드를 짜기 위해 ‘매핑하지 않기’ 전략이 웹 계층과 애플리케이션 계층 사이, 애플리케이션 계층과 영속성 계층 사이에서 첫 번째 선택지가 돼야 한다. 하지만 애플리케이션 계층에서 영속성 문제나 웹 문제를 다뤄야 하게 되면 웹 계층과 애플리케이션 계층, 애플리케이션 계층과 영속성 계층 사이에서 각각 ‘양방향’ 매핑 전략으로 바꿔야 한다.

출처

• 만들면서 배우는 클린 아키텍처 - 자바 코드로 구현하는 클린 웹 애플리케이션****