✅ 경계 간 매핑하기

🔗 매핑하지 않기 전략

웹 계층, 애플리케이션 계층 모두 Account 클래스에 접근하고 있다.

웹 계층에서는 Rest로 모델을 노출시킨다면, 직렬화 관련 애너테이션을 붙일 수 있다. 영속성 계층은 DB매핑을 위한 특정 애너테이션이 필요할 것이다.
각 관심사 분리를 위해 계층을 나눴지만, Account 도메인 모델은 모든 관심사를 포함하고 있어야 한다. 즉, 단일 책임 원칙을 위반하게 된다.

모든 계층이 정확히 같은 구조라면 고려해볼만하지만, 구조는 언제든 변경될 수 있기에 추천하진 않는다.

🔗 양방향 매핑 전략

각 계층은 도메인 모델과 다른 구조의 전용 모델을 가지도록 한다. 웹 계층에서 인커밍 포트(SendMoneyUseCase)에 필요한 도메인 모델로 매핑하고, 인커밍 포트에 의해 반환된 도메인 객체를 다시 웹 모델로 매핑한다.

하지만 아래와 같은 단점이 존재한다.

• 보일러플레이트 코드가 많아짐
• 도메인 모델이 계층 경계를 넘어서 통신하는데 사용됨
  인커밍 포트와 아웃고인 포트는 도메인 객체를 입력 파라미터와 반환값으로 사용하므로 도메인 모델의 필요에 의해서 변경되지 않고 바깥쪽 계층의 요구에 따른 변경에 취약해진다.

🔗 완전 매핑 전략

각 연산마다 별도의 입출력 모델을 사용하는 것이다. 통신할 때 또한 특화된 모델을 사용한다. (command, Request)

• 웹 계층: 애플리케이션 계층의 커맨드 객체로 매핑, 해당 커맨드 객체는 검증 로직 + 전용 필드 가짐
• 애플리케이션 계층: 커맨드 객체를 유스케이스에 따라 도메인 모델을 변경하기 위해 필요한 무언가로 매핑

웹 계층과 애플리케이션 계층 사이에서 상태 변경 유스케이스의 경계를 명확하게 할 때 가장 빛을 발한다. 애플리케이션 계층과 영속성 계층 사이에서는 매핑 오버해드 때문에 사용하지 않는 것이 좋다.

🔗 단방향 매핑 전략

모든 계층이 같은 인터페이스를 구현하고 있다. 이 인터페이스는 Attribute에 대한 getter 메서드를 제공해 도메인 모델의 상태를 캡슐화한다.

이 매핑은 팩터리라는 DDD 개념과 잘 어울리며, 계층 간의 모델이 비슷할 때(읽기 전용) 가장 효과적이다.

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

시간이 지나며 변화를 거듭하기에 고정된 매핑 전략으로 유지하기보다, 간단한 전략으로 시작해 계층 간 결합을 떼어내는 것도 도움이 된다.

• 변경 유스케이스 작업

  • 웹 - 애플리케이션 사이: 완전 매핑
  • 애플리케이션 - 영속성 사이: 매핑하지 않기 or 양방향 (애플리케이션에서 영속성 문제를 다뤄야 한다면)

• 쿼리

  • 웹 - 애플리케이션 사이: 매핑하지 않기
  • 애플리케이션 - 영속성 사이: 매핑하지 않기
  • 애플리케이션에서 웹 or 영속성 문제 다룬다면 각각 양방향 매핑 정략

✅ 결론

각 유스케이스에 대해 좁은 포트를 사용하면 유스케이스마다 다른 매핑 전략을 사용할 수 있고, 서로 영향을 미치지 않을 수 있으므로 최선의 전략을 선택할 수 있다.

상황별로 매핑 전략을 선택하는 것은 많은 커뮤니케이션을 필요로 하겠지만, 유지보수하기 쉬운 코드가 될 수 있다.