경계 간 매핑 전략
여러가지 매핑 전략을 섞어쓸 수 있으며, 전역 규칙일 필요가 없다!
매핑하지 않기 전략
웹 계층과 애플리케이션 계층 모두 같은 모델 사용
웹 계층과 영속성 계층은 모델에 대해 특별한 요구사항이 있을 수 있다
ORM 프레임워크를 사용한다면 데이터베이스 매핑을 위한 특정 어노테이션이 필요할 수 있는데, 이 방식을 사용하면 도메인 클래스가 웹, 애플리케이션, 영속성 계층과 관련된 이유로 수시로 변경될 수 있고, 단일 책임 원칙을 위반하게 되는 단점이 있다.
모든 계층이 같은 구조와 같은 정보를 필요로 한다면 충분히 좋은 방식
매핑 방식을 간단하게 시작했다가 나중에 언제든 변경할 수 있다.
양방향 매핑
웹 모델을 인커밍포트에서 필요한 도메인 모델로 매핑하고, 반대로 인커밍포트에서 반환된 도메인 모델을 웹 모델로 매핑하는 방식
각 계층이 전용 모델을 가지고 있어 변경되더라도 다른 계층에 영향이 적다
웹 모델은 데이터를 최적으로 표현할 수 있는 구조를 가지고, 도메인 모델은 유스케이스를 잘 구현할 수 있는 구조를 가지고, 영속성 모델은 DB에 객체를 저장하기 위해 ORM에서 필요한 구조를 가질 수 있다.
단일 책임 원칙을 만족
너무 많은 보일러플레이트 코드가 생기며, 도메인 모델을 계층 경계를 넘어 통신하는 데에 사용되어 바깥 계층의 요구에 의한 변경에 취약하다.
완전 매핑 전략
각 연산마다 입출력 모델을 사용
커맨드, 요청 등의 단어를 사용해 유스케이스 인커밍포트의 입력 모델을 두고, 모델 클래스 내부에서 유효성 검증 로직을 가진다.
여러 유스케이스의 요구사항을 함께 다뤄야 하는 매핑에 비해 구현과 유지보수가 쉬움
웹 계층과 애플리케이션 계층 사이에 상태 변경 유스케이스의 경계를 명확히 할 때 좋다
입력 모델만 이 매핑 방식을 사용하고, 반환할 때는 도메인 객체를 출력 모델로 사용해도 좋다.
단방향 매핑 전략
모든 계층의 모델들이 같은 인터페이스를 구현
관련있는 attribute들에 대한 getter 메서드를 제공해 도메인 모델의 상태를 캡슐화
인터페이스를 구현하므로 매핑을 없앨 수 있다.
행동을 변경하는 것이 인터페이스에 의해 노출되지 않으므로 상태 변경 위험이 없다.
다른 계층으로부터 받은 객체를 해당 객체에서 이용할 수 있도록만 매핑하는 방식
계층 간 모델이 비슷할 때 효과적
전략 사용 방법
변경 유스케이스 작업
웹 계층 - 애플리케이션 계층
유스케이스 간 결합 제거를 위해 완전 매핑을 첫 선택지로 두기
유스케이스 별 유효성 검증 규칙이 명확해지고 특정 유스케이스에서 필요하지 않은 필드는 다루지않아도 됨
애플리케이션 계층 - 영속성 계층
매핑 오버헤드를 줄이고 빠르게 코드 짜기 위해 매핑하지 않기 전략을 첫 선택지로 두기
애플리케이션 계층에서 영속성을 다뤄야하는 상황이라면 양방향 매핑 전략 사용
단순 쿼리 유스케이스 작업 (아마 조회성인 것 같음)
웹-애플리케이션-영속성 모두 매핑하지 않기를 첫 선택지로 두기
애플리케이션에서 영속성이나 웹 문제를 다뤄야 하면 양방향 매핑 전략 사용하기
Last updated