매핑에 찬성하는 개발자
- 계층의 결합을 막자!!
매핑에 반대하는 개발자
- 보일러플레이트 코드가 너무 심하다!
- 나도 알아 안다고! 근데 딱봐도 CRUD 밖에 안하잖아요!
- 너무 과합니다!
정답은 없다. 여러 매핑 전략을 알아보자
매핑하지 않기 전략
포트 인터페이스가 도메인 모델을 입출력 모델로 사용한다.
양방향 매핑 전략
각 어댑터(웹 어댑터(컨트롤러)), 영속성 어댑터(리포지토리))가 전용 모델을 가진다.
웹 어댑터는 웹 모델(컨트롤러 DTO)을 도메인 엔티티 모델로 영속성 어댑터는 도메인 엔티티를 영속성 모델(JpaEntity)로 바꿀 책임을 가진다
완전 매핑 전략
각 어댑터는 물론 포트 까지 전용 모델을 가진다.
이 매핑 전략을 전역 패턴으로 추천하지 않는다. 이 전략은 웹 계층과 애플리케이션 계층 사이 상태 변경 유스케이스의 경계를 명확하게 할 때 가장 빛난다.애플리케이션과 영속성 계층 사이에서는 매핑 오버 헤드 때문에 사용하지 않는 것이 좋다.또한 어떤 경우에는 연산의 입력 모델에 대해서만 이 매핑을 사용하고, 도메인 객체를 그대로 출력 모델로 사용하는 것도 좋다.
단방향 매핑 전략
엔티티의 필드에 대한 getter 메서드를 제공하는 AccountState 인터페이스를 둔다 서비스를 제외하고 전역적으로 활용한다. 엔티티 자체도 AccountState 인터페이스를 구현한다!!
장점 및 네이밍 이유를 소개하지만 다른 전략보다 조금 어렵다.
도메인 모델 자체는 Rich 하게 가져갈 수 있다.
놀라운 사실
- 어떤 매핑 전략을 사용해야 하는가에 대한 대답은 물론
그때 그때 다르다.
- 한 전략을 전체 코드에 대한 어떤 경우에도 변하지 않는 전역 규칙으로 정의하려는 충동을 이겨내야 한다.
- 언제 어떤 전략을 사용할지 결정하려면 팀 내에서 합의할 수 있는 가이드라인을 정해둬야 한다.
- 예를 들어, 변경 유스케이스(커맨드)와 쿼리 유스케이스에서 서로 다른 매핑 가이드라인을 둘 수 있다.
- 또
컨트롤러 <-> 서비스 계층 사이와서비스 <-> 영속성 계층 사이전략을 다르게 가져갈 수도 있다. 숙소 도메인과회원 도메인의 전략을 다르게 가져갈 수도 있다.