경계 간 매핑

• 경계간 매핑 여부에 대해서 두 가지 의견이 있다.

  1. 매핑 찬성
     1. 매핑을 안하면 두 계층이 강결합된다.
  2. 매핑 반대
     1. 매핑 자체가 보일러 플레이트 코드가 너무 많다.
     2. 모든 계층에 걸쳐 같은 모델을 사용하는데 계층 간 매핑은 과하다.

• 둘 다 일리는 있다.

매핑을 아예 안하면

1. 모델에 JSON 관련 어노테이션을 붙여야 할 수도 있다.
2. 모델이 여러 이유로 변경돼야 할 수도 있다. 이는 단일 책임 원칙을 위반한다. 또한 각 계층에서만 필요한 필드들은 파편화된 도메인 모델을 만든다.
3. 물론 모든 계층이 정확히 같은 구조로, 정확히 같은 정보를 필요로 하면 나쁘지 않은 선택이다.

양방향 매핑

• 각 계층이 전용 모델을 가진 경우를 의미한다.
  • input, output adapter, service 마다 모델이 있다.
• 각 계층이 전용 모델을 가져서 전용 모델을 변경해도 계층 간 영향이 거의 없다.
• 그러나 보일러 플레이트 코드가 많아진다. (은총알이 아니다.)

완전 매핑

• 계층을 넘어서 연산 마다 모델을 사용한다.
• 각 작업에 특화된 모델을 사용한다. (command, request 등을 붙여서)
• 커맨드 객체가 UseCase에서 무엇을 하기 위한 행동이 된다.
• 여러 유스케이스의 요구 사항을 함께 다뤄야 하는 매핑에 비해 유지보수가 쉬워진다.
• 계층 사이에 상태 변경 유스케이스의 경계를 명시할 때 빛이 난다.

단방향

• 인터페이스를 하나 두고 각 계층에서 이를 구현 모델로 움직인다. 이러면 자연스럽게 변환하는 과정이 빠지게 된다.
• 특성에 대해서 캡슐화하고 각 계층 간 간섭을 줄일 수 있다.
• 실수로 도메인 객체 상태를 변경하는 일을 줄일 수 있다.

• 매핑 책임이 명확하다.

• 전략은 상황에 맞게 선택해야 한다.

유지보수성

• 각 UseCase에 대해서 좁은 포트를 사용하면 UseCase 별로 다른 매핑 전략을 사용할 수 있다.
• 다른 UseCase에 영향을 주지 않으면서 코드를 개선할 수 있기 때문에 특정 상황, 특정 시점에 최선의 전략을 선택할 수 있다.