각 계층의 모델을 매핑할 때의 논쟁점
매핑 찬성
두 계층 간에 매핑을 하지 않으면 양 계층에서 같은 모델을 사용해야 하는데, 이러면 두 계층이 강하게 결합된다.
매핑 반대
두 계층 간에 매핑을 하게 되면 보일러플레이트 코드를 너무 많이 만들게 된다. 많은 유스케이스들이 오직 CRUD만 수행하고 계층에 걸쳐 같은 모델을 사용하기 때문에 계층 사이의 매핑을 과하다.
포트 인터페이스가 도메인 모델을 입출력 모델로 사용하면 두 계층 간의 매핑을 할 필요가 없다.
웹 계층에서는 웹 컨트롤러가 SendMoneyUseCase 인터페이스를 호출해서 유스케이스를 실행한다. 이 인터페이스는 Account 객체를 인자로 가진다. 즉, 웹 계층과 애플리케이션 계층 모두 Account 클래스에 접근해야 한다는 것을 의미한다. (두 계층이 같은 모델을 사용)
반대쪽의 영속성 계층과 애플리케이션 계층도 같은 관계다. 모든 계층이 같은 모델을 사용하니 계층 간 매핑을 할 필요가 없다.
이 설계를 판단했을때
웹 계층과 영속성 계층은 모델에 대해 특별한 요구사항이 있을 수 있다. 예를 들어, 웹 계층에서 REST로 모델을 노출시켰다면 모델을 JSON으로 직렬화하기 위한 애너테이션을 모델 클래스의 특정 필드에 붙여야 할 수도 있다. 영속성 계층에 대해서도 마찬가지다. ORM 프레임워크를 사용한다면 DB 매핑을 위한 특정 애너테이션이 필요할 것이다.
도메인과 애플리케이션 계층은 웹이나 영속성과 관련된 특수한 요구사항에 관심이 없음에도 불구하고 Account 도메인 모델 클래스는 이런 모든 요구사항을 다뤄야 한다.
Account 클래스는 웹, 애플리케이션, 영속성 계층과 관련된 이유로 인해 변경돼야 하기 때문에 단일 책임 원칙을 위반한다.
기술적인 요구사항이 아니더라도, 각 계층이 Account 클래스에 특정 커스텀 필드를 두도록 요구할 수 있다. 그 결과, 오로지 한 계층에서만 필요한 필드들을 포함하는 파편화된 도메인 모델로 이어질 수 있다.
매핑하지 않기 전략이 딱 들어맞을 때가 있다.
간단한 CRUD 유스케이스를 생각했을 때, 같은 필드를 가진 웹 모델을 도메인 모델로, 혹은 도메인 모델을 영속성 모델로 매핑할 필요가 없다.
그러나 애플리케이션 계층이나 도메인 계층에서 웹과 영속성 문제를 다루게 되면 곧바로 다른 전략을 취해야 한다.
어떤 매핑 전략을 선택했더라도 나중에 언제든 바꿀 수 있다.
각 계층이 전용 모델을 가진 매핑 전략을 양방향(Two-Way) 매핑 전략이라고 한다.