> For the complete documentation index, see [llms.txt](https://develop-footprint.gitbook.io/o/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://develop-footprint.gitbook.io/o/programming/clean-architecture/clean-book/6.md).

# 경계 간 매핑 전략

{% hint style="info" %}
여러가지 매핑 전략을 섞어쓸 수 있으며, 전역 규칙일 필요가 없다!
{% endhint %}

### 매핑하지 않기 전략

* 웹 계층과 애플리케이션 계층 모두 같은 모델 사용
* 웹 계층과 영속성 계층은 모델에 대해 특별한 요구사항이 있을 수 있다
* ORM 프레임워크를 사용한다면 데이터베이스 매핑을 위한 특정 어노테이션이 필요할 수 있는데, 이 방식을 사용하면 도메인 클래스가 웹, 애플리케이션, 영속성 계층과 관련된 이유로 수시로 변경될 수 있고, **단일 책임 원칙을 위반**하게 되는 단점이 있다.
* 모든 계층이 같은 구조와 같은 정보를 필요로 한다면 충분히 좋은 방식
* 매핑 방식을 간단하게 시작했다가 나중에 언제든 변경할 수 있다.

### 양방향 매핑

* 웹 모델을 인커밍포트에서 필요한 도메인 모델로 매핑하고, 반대로 인커밍포트에서 반환된 도메인 모델을 웹 모델로 매핑하는 방식
* 각 계층이 전용 모델을 가지고 있어 변경되더라도 다른 계층에 영향이 적다
* 웹 모델은 데이터를 최적으로 표현할 수 있는 구조를 가지고, 도메인 모델은 유스케이스를 잘 구현할 수 있는 구조를 가지고, 영속성 모델은 DB에 객체를 저장하기 위해 ORM에서 필요한 구조를 가질 수 있다.
* 단일 책임 원칙을 만족
* 너무 많은 보일러플레이트 코드가 생기며, 도메인 모델을 계층 경계를 넘어 통신하는 데에 사용되어 바깥 계층의 요구에 의한 변경에 취약하다.

### 완전 매핑 전략

* 각 연산마다 입출력 모델을 사용
* 커맨드, 요청 등의 단어를 사용해 유스케이스 인커밍포트의 입력 모델을 두고, 모델 클래스 내부에서 유효성 검증 로직을 가진다.
* 여러 유스케이스의 요구사항을 함께 다뤄야 하는 매핑에 비해 구현과 유지보수가 쉬움
* 웹 계층과 애플리케이션 계층 사이에 상태 변경 유스케이스의 경계를 명확히 할 때 좋다
* 입력 모델만 이 매핑 방식을 사용하고, 반환할 때는 도메인 객체를 출력 모델로 사용해도 좋다.

### 단방향 매핑 전략

* 모든 계층의 모델들이 같은 인터페이스를 구현
* 관련있는 attribute들에 대한 getter 메서드를 제공해 도메인 모델의 상태를 캡슐화
* 인터페이스를 구현하므로 매핑을 없앨 수 있다.
* 행동을 변경하는 것이 인터페이스에 의해 노출되지 않으므로 상태 변경 위험이 없다.
* 다른 계층으로부터 받은 객체를 해당 객체에서 이용할 수 있도록만 매핑하는 방식
* 계층 간 모델이 비슷할 때 효과적

### 전략 사용 방법

* 변경 유스케이스 작업
  * 웹 계층 - 애플리케이션 계층
    * 유스케이스 간 결합 제거를 위해 완전 매핑을 첫 선택지로 두기
    * 유스케이스 별 유효성 검증 규칙이 명확해지고 특정 유스케이스에서 필요하지 않은 필드는 다루지않아도 됨
  * 애플리케이션 계층 - 영속성 계층
    * 매핑 오버헤드를 줄이고 빠르게 코드 짜기 위해 매핑하지 않기 전략을 첫 선택지로 두기
    * 애플리케이션 계층에서 영속성을 다뤄야하는 상황이라면 양방향 매핑 전략 사용
* 단순 쿼리 유스케이스 작업 (아마 조회성인 것 같음)
  * 웹-애플리케이션-영속성 모두 매핑하지 않기를 첫 선택지로 두기
  * 애플리케이션에서 영속성이나 웹 문제를 다뤄야 하면 양방향 매핑 전략 사용하기