경계 간 매핑하기

매핑에 따른 의견

매핑에 찬성하는 개발자 

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

 

매핑에 반대하는 개발자

두 계층 간에 매핑을 하게 되면 보일러 플레이트 코드를 너무 많이 만들게 된다. 많은 유스케이스들이 오직 CRUD만 수행하고 계층에 걸쳐 같은 모델을 사용하기 때문에 계층 사이의 매핑은 너무 과하다.

 

매핑하지 않기

매핑하지 않는 전략을 사용하게 된다면 그림은 위 처럼 된다. 송금하기 위한 모든 클래스들이 Account 클래스를 참조하고 있다. 도메인과 어플리케이션 계층은 웹이나 영속성과 관련된 특수한 요구사항에 관심이 없음에도 불구하고 Account 도메인 모델 클래스는 모든 요구사항을 다뤄야 한다. Account클래스는 웹, 어플리케이션, 영속성 계층과 관련된 이유로 인해 변경해야 하기 때문에 단일 책임 원칙을 위반한다. 하지만, 모든 계층에서 정확히 같은 구조의 정확히 같은 정보를 필요로 한다면 '매핑하지 않기' 전략은 완벽한 선택지다. 

 

양방향 매핑 전략

각 계층이 전용 모델을 가진 매핑 전략을 양방향 매핑 전략이라고 한다. 계충 서로가 매핑하기 때문에 '양방향'매핑 이라고 부른다.

• 웹 모델을 인커밍 포트를 통해 모데인 모델로 매핑하고, 인커밍 포트에 의해 반환된 도메인 객체를 다시 웹 모델로 매핑한다. 
• 영속성 계층은 아웃고잉 포트가 사용하는 도메인 모델과 영속성 모델 간의 매핑과 유사한 매핑을 담당한다.

계층 마다 전용 모델을 가지고 있기 때문에 각 계층이 전용 모델을 변경하더라도 다른 계층에는 영향이 없다. 

 

양방향 매핑의 단점

• 양방향 매핑은 너무 많은 보일러플레이트 코드가 생긴다. 
• 도메인 모델은 도메인으 필요에 의해서 변경되는 것이 이상적이지만 바깥쪽 계층 요구에 따른 변경에 취약해진다.
• 개발을 불필요하게 더디게 만든다.

 

완전 매핑 전략

각 연산마다 별도의 입출력 모델을 사용한다. 계층 경계를 넘어 통신 할 때 도메인 모델을 사용하는 대신 SendMoneyCommand처럼 SendMoneyUseCase에 특화된 모델을 사용한다. 

 

완전 매핑 전략의 단점

• 매핑 오버헤드가 발생 할 수 있다.

 

단방향 매핑 전략

모든 계층의 모델들이 같은 인터페이스를 구현한다. 이 인터페이스는 관련 있는 특성에 대한 getter 메서드를 제공해서 모데인 모델의 상태를 캡슐화 한다.

도메인 모델 자체는 풍부한 행동을 구현 할 수 있고, 어플리케이션 계층 내의 서비스에서 이러한 행동에 접근 할 수 있다. 또, 인터페이스를 구현하고 있기 때문에 도메인 객체 바깥으로 매핑없이 이동시킬 수 있다. 그 이후에 전용 인터페이스를 사용할지 전용 모델로 매핑할지 `선택` 할 수 있게 된다. 

 

언제 어떤 매핑 전략을 사용 할 것인가?

각 매핑 전략이 저마다 장단점을 가지고 있기 때문에 한 전략을 전체 코드에 대한 어떤 경우에도 변하지 않는 전역 규칙으로 정의하려는 충동을 이겨내야 한다. 

• 빠르게 코드를 할 수 있는 간단한 전략으로 시작해서 계층 간 결합을 떼어내는데 도움이 되는 복잡한 방법으로 갈아나는 방법
• 가이드를 미리 정해둬야 한다.
• 예) 변경 유스케이스를 작업하고 있다면 웹 계층과 어플리케이션 계층 사이에서는 유스케이스 간의 결합을 제거하기 위해 완전 매핑 전략을 첫 번째 선택지로 택해야 한다.