경계 간 매핑하기
“매핑하지 않기” 전략
장점
CRUD와 같은 단순 작업에서는 좋다.
모든 계층이 정확히 같은 구조의, 정확히 같은 정보를 필요로 한다면 완벽한 선택지이다.
문제점
웹, 애플리케이션, 영속성 계층과 관련된 이유로 인해 변경돼야 하기 때문에 단일 책임 원칙을 위반한다.
각 계층이 특정 커스텀 필드를 두도록 요구할 수 있다. 그 결과, 오로지 한 계층에서만 필요한 필드들을 포함하는 파편화된 도메인 모델로 이어질 수 있다.
“양방향” 매핑 전략
장점
각 계층이 전용 모델을 가지고 있는 덕분에 각 계층이 전용 모델을 변경하더라도 다른 계층에 영향이 없다.
그래서 웹 모델은 데이터를 최적으로 표현할 수 있는 구조를 가질 수 있고, 도메인 모델은 유스케이스를 제일 잘 구현할 수 있는 구조를 가질 수 있다.
단점
너무 많은 보일러플레이트 코드가 생긴다.
도메인 모델이 계층 경계를 넘어서 통신하는 데 사용되고 있다.
“완전” 매핑 전략
각 연산이 전용 모델을 필요로 하기 떄문에 웹 어댑터와 애플리케이션 계층 각각이 자신의 전용 모델을 각 연산을 실행하는 데 필요한 모델로 매핑한다.
한 계층을 다른 여러 개의 커맨드로 매핑하는 데는 하나의 웹 모델과 도메인 모델 간의 매핑보다 더 많은 코드가 필요하다. 하지만 이렇게 매핑하면 여러 유스케이스의 요구사항을 함께 다뤄야 하는 매핑에 비해 구현하고 유지보수하기가 훨씬 쉽다.
이 매핑 전략을 전역 패턴으로 추천하지는 않는다. 이 전략은 웹 계층(혹은 인커밍 어댑터 종류 중 아무거나)과 애플리케이션 계층 사이에서 상태 변경 유스케이스의 경계를 명확하게 할 때 가장 빛을 발한다. 애플리케이션 계층과 영속성 계층 사이에서는 매핑 오버헤드 때문에 사용하지 않는 것이 좋다.
“단방향” 매핑 전략
동일한 상태 인터페이스를 구현하는 도메인 모델과 어댑터 모델을 이용하면 각 계층은 다른 계층으로부터 온 객체를 단방향으로 매핑하기만 하면 된다.
이 매핑은 팩터리라는 DDD 개념과 잘 어울린다. DDD 용어인 팩터리는 어떤 특정한 상태로부터 도메인 객체를 재공성할 책임을 가지고 있다.
계층 간의 모델이 비슷할 때 가장 효과적이다.
언제 어떤 매핑 전략을 사용할 것인가?
그때그때 다르다.
각 매핑 전략이 저마다 장단점을 가지고 있기 때문에 한 전략을 전체 코드에 대한 어떤 경우에도 변하지 않는 전역 규칙으로 정의하려는 충동을 이겨내야 한다.
변경 유스케이스를 작업하고 있다면 웹 계층과 애플리케이션 계층 사이에서는 유스케이스간의 결합을 제거하기 위해 ‘완전 매핑’ 전략을 첫 번째 선택지로 선택해야 한다. 이렇게 하면 유스케이스별 유효성 검증 규칙이 명확해지고 특정 유스케이스에서 필요하지 않은 필드를 다루지 않아도 된다.
변경 유스케이스를 작업하고 있다면 애플리케이션과 영속성 계층 사이에서는 매핑 오버헤드를 줄이고 빠르게 코드를 짜기 위해서 매핑하지 않기 전략을 첫 번째 선택지로 둔다. 하지만 애플리케이션 계층에서 영속성 문제를 다뤄야 하게 되면 ‘양방향’ 매핑 전략으로 바꿔서 영속성 문제를 영속성 계층에 가둘 수 있게 한다.
쿼리 작업을 한다면 매핑 오버헤드를 줄이고 빠르게 코드를 짜기 위해 ‘매핑하지 않기’ 전략이 웹 계층과 애플리케이션 계층 사이, 애플리케이션 계층과 영속성 계층 사이에서 첫 번째 선택지가 돼야 한다. 하지만 애플리케이션 계층에서 영속성 문제나 웹 문제를 다뤄야 하게 되면 웹 계층과 애플리케이션 계층, 애플리케이션 계층과 영속성 계층 사이에서 각각 ‘양방향’ 매핑 전략으로 바꿔야 한다.
Last updated
