12/04 TIL

[eggnee]

ApiResponse 지양

ApiResponse는 과거에 널리 사용되던 응답 방식으로, 고정된 구조로 데이터를 반환하는 데 편리했다. 하지만 최근에는 HTTP 상태 코드의 중복 문제와 RESTful 설계 원칙을 위배한다는 점에서 지양하는 추세다.

ApiResponse는 성공과 실패 여부를 응답 객체의 특정 필드(success, errorCode)로 표현하면서 HTTP 상태 코드를 제대로 활용하지 못하는 경우가 많았다. 또한, RESTful API는 HTTP 상태 코드를 최대한 활용하는 것을 권장하는데, ApiResponse는 이를 따르지 않아 일관성이 부족한 설계로 이어졌다.

현대적인 개발 환경에서는 ResponseEntity를 사용해 HTTP 상태 코드와 함께 최소한의 데이터만을 응답하는 방식이 더 적합하다. 이 방법을 사용하면 RESTful 원칙을 준수하면서 클린한 API 설계를 구현할 수 있다.

---

VO 패키지 설계

이전 프로젝트에서는 domain 패키지 아래에 vo 패키지를 따로 만들어, 열거형(enum) 상태 값이나 원시 타입을 포장한 객체들을 관리했다. 하지만 요즘 아키텍처에서는 이렇게 따로 패키지로 분리하지 않는 추세다.

VO(Value Object)는 불변성을 가지는 도메인 객체로 주로 사용되지만, 최근에는 VO를 별도의 패키지로 분리하기보다는 도메인 모델에 포함시키는 방식이 일반적이다. 예를 들어, Address VO는 User와 같은 도메인 모델 내부에서 자연스럽게 사용한다. VO 패키지를 따로 두면 유지보수성이 떨어지고, 패키지가 복잡해질 가능성이 크기 때문이다.

또한, 불변성과 가변 객체를 명확히 나누기보다는 필요할 때만 불변 객체를 사용하는 경우가 많아졌다. 예를 들어, Java의 record 타입을 사용하면 간단히 불변 객체를 생성할 수 있다.

public record Address(String street, String city, String zipCode) {}

요즘의 설계에서는 불변 객체가 필요할 때만 생성하고, 일반적인 상황에서는 DTO와 같은 단순한 데이터 클래스를 사용하는 것이 더 효율적이다. VO는 특정 패키지에 고정적으로 분리하기보다는 도메인 모델 내부에서 자연스럽게 포함하며, 필요한 경우 유연하게 활용하는 방식이 주로 사용된다.