각 계층 간을 오고 가는 데이터 모델을 하나의 모델로 오고 갈 것인가?
아니면 계층이 변화될 때 계층에 걸맞은 데이터 모델로 새로 매핑할 것인가?
두 계층에서 같은 모델을 사용한 적이 있을 것이다.
두 계층을 오고 갈 때 매핑하지 않으면 양 계층에서 같은 모델을 사용해야 하고, 그로 인해 두 계층이 강하게 결합된다.
계층을 이동할 때마다 새로운 모델로 매핑하게 되면 비슷한 형태를 가지고 있는 코드들이 너무 많이 만들어진다.
또한 CRUD를 수행하는 유스케이스들은 같은 모델을 사용하기 때문에 계층 사이 마다의 매핑은 과하다.
여러 계층을 거쳐서 사용하는 도메인 모델은 각 계층마다의 요구사항을 충족해야 하기 때문에 여러 계층에서 사용하는 어노테이션을 붙이게 될 가능성이 높다.
ex) 웹 계층 : 특정 기능을 위한 어노테이션
영속성 계층 : ORM 프레임워크 사용 시 데이터베이스 매핑을 위한 어노테이션
결국 예시에서의 Account 클래스는 웹/어플리케이션/영속성 계층 각각에 관련된 이유로 변경되기 때문에 단일 책임 원칙을 위반하게 된다.
하지만 앞선 이야기들과 다르게 모든 계층이 같은 구조, 같은 정보를 필요로 한다면 '매핑하지 않기' 전략이 필요한 경우도 있다.
ex) 간단한 CRUD 유스케이스
데이터베이스를 기반으로 같은 필드를 사용하는 작업이라면 대해 웹-어플리케이션-영속성 계층을 오고 가는 모델을 굳이 매핑할 필요는 없을 것이다.
웹 계층에서는 웹모델을 인커밍 포트에서 필요한 도메인 모델로 매핑하고, 인커밍 포트에 의해 반환된 도메인 객체는 다시 웹모델로 매핑한다.
영속성계층에서는 아웃고잉 포트가 사용하는 도메인 모델과 영속성 모델 간의 매핑과 유사한 매핑을 담당한다.
각 계층이 전용 모델을 가지고 있기 때문에 모델에 수정이 일어나더라도 다른 계층에 영향을 미치지 않는다.
양방향 매핑 전략은 웹이나 영속성 계층과 독립적인 도메인 모델을 가지고 있기 때문에 불필요한 필드나 어노테이션을 가지고 있지 않고, 도메인 모델은 다른 계층의 속성에 의해 수정되지 않는다.
또한 비교적 간단한 작업으로 매핑 책임을 명확하게 구분할 수 있다는 장점이 있다.
계층을 넘나드는 인터페이스에서 이동하는 방향에 따라 모델로 매핑하고, 각 계층에서의 전용 모델에만 집중하여 작업할 수 있다.
하지만 각 계층마다 전용 모델을 만들다 보니 너무 많은 중복 코드 (보일플레이트 코드)가 생긴다.
또한 도메인 모델이 계층 경계를 넘어 통신하는 데 사용되고 있다.
인커밍 포트에서는 도메인 객체를 어플리케이션 계층으로 진입하는 입력 파라미터로, 아웃고잉 포트에서는 도메인 객체를 반환값으로 사용하기 때문에 결국 바깥쪽 계층의 요구에 따른 변경에 취약해진다.
계층 간 경계를 넘어 통신할 때 도메인 모델을 사용하지 않고 유스케이스 포트의 입력 모델로 동작하도록 특화된 모델을 사용한다. (command 혹은 request)
웹 계층에서 어플리케이션 계층으로 통신할 때, 그 사이의 커맨드 객체로 매핑해준다.
커맨드 객체에서 웹모델이 어플리케이션 계층으로 통신하면서 입력 모델에 대한 유효성 검증 로직을 수행한다.
여러 계층과 여러 커맨드로 매핑하면서 더 많은 코드가 필요하지만, 여러 유스케이스의 요구사항을 다루어야 하는 매핑에 비해 구현과 유지 보수가 쉽다.
완전 매핑 전략은 외부 인터페이스와 통신하는 인커밍 어댑터와 어플리케이션 계층 사이에서 상태 변경 유스케이스의 경계를 명확하게 할 때 제 역할을 한다.
인터페이스는 관련 있는 특성에 대한 getter 메소드를 제공해서 도메인 모델의 상태를 캡슐화한다.
해당 전략에서는 어플리케이션 계층과 바깥 계층을 오고 가는 모델들은 도메인 객체가 인커밍/아웃고잉 포트가 기대하는 상태로 인터페이스를 구현하고 있기 때문에 매핑없이 전달할 수 있다.
어플리케이션 계층에서는 이 객체를 실제 도메인 모델로 매핑해서 도메인 모델의 행동에 접근할 수 있게 된다.
작업할 계층이 다른 계층으로부터 객체를 건내받으면 해당 계층에서 이용할 수 있도록 인터페이스를 구현하고 있는 다른 무언가로 매핑하고 한 방향으로만 매핑하기 때문에 '단방향' 전략이다.
같은 인터페이스를 구현하기 때문에 계층 간 모델이 비슷할 때 가장 효과적이고 읽기 전용 연산인 경우 여러 모델로 매핑할 필요가 없다.
- 여러 가지의 매핑 전략이 혼재할 수 있다.
- 시간이 지나 매핑 전략에 변경이 필요할 수 있다.
계층 사이에서 문지기처럼 동작하는 인커밍포트와 아웃고잉 포트는 서로 다른 계층간에 어떤 매핑 전략을 사용할 것인가에 대한 선택이 포함된다.
팀 차원에서의 논의를 거쳐 해당 프로젝트의 특성을 고려한 규칙적인 가이드라인을 구축하여 훌륭하게 지킨다면 유지 보수하기 좋은 코드를 기대할 수 있다.