8장 - 경계 간 매핑하기

매핑에 찬성하는 개발자

두 계층을 매핑하지 않으면 양 계층을 같은 모델에 사용해야 하고 두 계층이 강하게 결합된다.

 

매핑에 찬성하지 않는 개발자

매핑을 위해 너무 많은 보일러플레이트 코드가 생성된다.

많은 유스케이스들이 오직 CRUD만 수행하고 계층에 걸쳐 같은 모델을 사용하기 때문에 계층 사이의 매핑은 과하다

 

 

매핑하지 않기 전략

영속성 계층과 유스케이스에서 모두 Account 객체를 사용하는 경우입니다.

이렇게 REST를 위한 JSON 직렬화 애너테이션 또는 ORM 프레임워크를 위한 애너테이션이 필요하게 됩니다.

이렇게 되면 Account 객체에서 웹, 영속성과 관련된 특수한 요구사항에 관심이 없음에도 불구하고 모든 요구사항을 다루게 됩니다.

 

이제 Account 클래스는 웹, 애플리케이션, 영속성 계층과 관련된 이유로 변경되기 때문에 단일 책임 원칙을 위반합니다.

 

하지만 모든 계층이 같은 구조로 같은 정보를 필요로 한다면 매핑하지 않기 전략은 완변한 선택지입니다.

 

또한 매핑하지 않기 전략을 사용했다 매핑하는 전략으로 이동할 수 있기 때문에 언제든지 바꿀 수 있습니다.

 

양방향 매핑 전략

각 계층이 전용 모델을 가짐으로써 각 계층이 전용 모델을 변경하더라도 다른 계층에는 영향이 없습니다.

웹 모델은 데이터를 최적으로 표현할 수 있는 구조를 가지고, 도메인 모델은 유스케이스를 제일 잘 구현할 수 있는 구조를 가지며, 영속성 모델은 데이터베이스에 객체를 저장하기 위해 ORM에서 필요로 하는 구조를 가질 수 있습니다.

 

이제 단일책임원칙을 만족하게 됩니다.

 

하지만 너무 많은 보일러플레이트 코드가 생깁니다.

매핑 프레임워크를 사용하는 경우 내부 동작 방식을 제너릭 코드와 리플렉션 뒤로 숨긴다면 디버깅하는 일도 꽤나 고통스럽습니다.

 

또한 도메인 모델이 계층 모델 경계는 넘어서 통신하는 데 사용됩니다.

이는 도메인 모델은 도메인 모델뿐만 아니라 바깥쪽 계층의 요구에 따른 변경에도 취약해짐을 의미합니다.

 

완전 매핑 전략

별도의 입출력 모델을 사용합니다.

당연하지만 매핑하는데 더 많은 코드가 필요하게 됩니다.

 

애플리케이션 계층사이에서 상태 변경 유스케이스의 경계를 명확하게 할 때 가장 빛을 발하지만 이 전략을 모두 적용하는 것은 추천하지 않습니다.

 

단반향 매핑 전략

인터페이스를 두고 모든 계층이 이를 구현합니다.

 

 

결론

매핑 전략은 여러 가지 섞어쓸 수 있고 그래야만 합니다.

각 매핑 전략마다 장단점을 가지고 있으며 어제는 최선이었던 전략이 오늘은 아닐 수 있습니다.