헥사고날 아키텍처와 DDD를 프로젝트에 적용하면서,
가장 크게 부딪힌 문제 중 하나는 DTO ↔ Domain ↔ Entity 변환 책임을 어디에 둘 것인가였다.

처음에는 Service나 Controller 안에서 무심코 변환을 처리했는데, 시간이 지날수록 레이어 간 경계가 무너지고, 도메인 순수성이 오염되는 문제가 생기게 되었다.
그래서 레이어 간 변환 책임을 분리하는 기준을 명확히 잡았고, 그 결과 구조적 안정성과 변경 내성이 크게 좋아지게 되었다.

아래는 프로젝트 개발에서 적용한 구조이며 board 도메인에 게시글을 올리는 것을 예를 들어보자.

---

✅ 1. Web DTO ↔ Application DTO

• 위치: adapter/web/mapper/

📌 내가 이렇게 한 이유

• 헥사고날 아키텍처 관점에서 Web 계층은 단순히 외부 요청을 받아 UseCase(Application Service)로 전달하는 어댑터일 뿐이다.
• API에 맞춘 DTO(Web DTO)는 Swagger 문서, Validation, 필드명 등 프레젠테이션 요구사항을 반영해야 하고,
  내부 Application DTO는 오직 비즈니스 로직만 고려해야 한다.
• 따라서 WebMapper를 두어 Web DTO ↔ Application DTO 변환을 담당하게 하면,
  웹 계층과 애플리케이션 계층이 서로 침범하지 않는다.

// 📁 board/adapter/web/mapper/BoardWebMapper.java
@Component
public class BoardWebMapper {

    public CreateBoardRequest toApplicationDto(CreateBoardWebRequest request, Long userId) {
        return new CreateBoardRequest(request.title(), request.content(), userId);
    }

    public BoardWebResponse toWebDto(CreateBoardResponse response) {
        return new BoardWebResponse(response.boardId());
    }
}

---

✅ 2. Application DTO ↔ Domain Model

• 위치: application/mapper/

📌 내가 이렇게 한 이유

• ApplicationService는 유스케이스 조립과 트랜잭션 경계 관리에 집중해야 한다.
• Domain은 DTO라는 외부 구조를 전혀 몰라야 순수성이 보장된다.
• 따라서 중간에 Mapper를 두어 Application DTO ↔ Domain 변환을 책임지게 했다.
• 이때 변환은 양방향으로 필요하다.
  • Application Request DTO → Domain Model
  • Domain Model → Application Response DTO

// 📁 board/application/mapper/BoardMapper.java
@Component
public class BoardMapper {

    // Application Request DTO → Domain Model
    public Board toDomain(CreateBoardRequest request) {
        return Board.of(request.title(), request.content(), request.userId());
    }

    // Domain Model → Application Response DTO
    public CreateBoardResponse toResponse(Board board) {
        return new CreateBoardResponse(board.getId());
    }
}

---

✅ 3. Domain Model ↔ JPA Entity

• 위치: adapter/jpa/mapper/

📌 내가 이렇게 한 이유

• JPA Entity는 DB와의 저장/조회에 특화된 Persistence 모델이다.
• Domain Model은 순수한 비즈니스 규칙 표현에 집중해야 한다.
• 두 모델을 섞어 쓰면 도메인 모델이 JPA 어노테이션과 영속성 컨텍스트에 오염된다.
• 따라서 JPA Adapter 내부에서만 매핑을 허용했고, 이렇게 하면 도메인 계층은 JPA 존재 자체를 모르게 된다.

// 📁 board/adapter/jpa/mapper/BoardJpaMapper.java
@Component
public class BoardJpaMapper {

    public BoardEntity toEntity(Board board) {
        return BoardEntity.of(board.getId(), board.getTitle(), board.getContent(), board.getUserId());
    }

    public Board toDomain(BoardEntity entity) {
        return Board.of(entity.getId(), entity.getTitle(), entity.getContent(), entity.getUserId());
    }
}

---

📝 종합 요약 (구조적 위치 정리 + 이유)

변환 책임	위치	이유
Web DTO ↔ Application DTO	adapter/web/mapper/	API 표현과 내부 DTO를 분리 → 헥사고날 경계 명확화
Application DTO ↔ Domain	application/mapper/	Domain은 외부 DTO를 몰라야 함 → 순수성 유지. Request/Response 양방향 매핑 필요
Domain ↔ JPA Entity	adapter/jpa/mapper/	Persistence 전용, JPA 의존성 차단 → 도메인 오염 방지

---

🚀 결론

헥사고날 아키텍처 + DDD를 실무에 적용하면서 가장 크게 배운 점은
“도메인 순수성을 지키려면, 변환 책임을 반드시 경계에 두어야 한다”는 것이다.

• Web ↔ Application: 표현과 비즈니스 분리
• Application ↔ Domain: Request DTO에서 도메인으로 변환, 도메인에서 Response DTO로 변환
• Domain ↔ JPA Entity: Persistence와 비즈니스 분리

이렇게 각 계층의 관심사를 구분했더니,
코드 품질이 유지되고, 테스트가 단순해질 수 있으며, 각 계층의 의미를 더욱 명확화 할 수 있을 것 같다!