Attribute Converter 적용 후기

 도메인의 자유를 위하여!

Attirubute Converter는 무엇인가?

 후기를 먼저 남기기 전에 Attribute Converter가 무엇인지 간단히 알아보자.

 

 

 Attribute Converter는 JPA 2.1부터 적용되었으며, 이름 그대로 DB와 엔티티 객체 사이에서 컬럼(속성)을 변환시켜주는 녀석이다. 인터페이스 형태로 제공이 되기 때문에 별도의 클래스로 구현해서 변환에 적용해야 한다. 구현이 필요한 메서드 명이 다음처럼 매우 직관적이기 때문에 이해하기도 쉽고 부담이 크지 않다. 다음 인터페이스를 구현하고, Entity 속성에 @Converter(*. class)만 명시해주면 된다.

// Entity 속성 타입과 DB 컬럼의 타입을 파라미터로 받는다.
public interface AttributeConverter<X,Y> {

    // Entity 속성에서 DB 컬럼으로 변환하는 메소드
    public Y convertToDatabaseColumn (X attribute);

    // DB 컬럼에서 Entity 속성으로 변환하는 메소드
    public X convertToEntityAttribute (Y dbData);
}

적용 후기

왜 적용했나?

 주소에 관한 정보를 다루는 서비스를 구현해야 했다. 서비스에 관한 요구사항은 다음과 같았다.

 

• Entity 정보는 외부 서비스로부터 연동받아야 한다.

• Entity 정보를 상세 조회할 때, 주소 전체 값이 나타나야 한다.

• 광역시/도 조건으로 목록 조회할 수 있어야 한다.

• 광역시/도 조건과 함께 시/군/구 조건으로 목록 조회할 수 있어야 한다.

 가장 큰 키워드는 주소를 전체로도 가지고 있어야 하고, 광역시/도로 분류해야 하기도 했다. 그래서 처음 서비스를 설계할 때는 주소 전체를 광역시/도, 시/군/구 등과 같은 컬럼으로 나눠 저장하고 이를 따로따로 관리하려고 했다. 그런데 가장 큰 문제가 있었으니, 바로 주소를 외부 서비스에서 연동받는 것이었다. 

 

 외부 서비스는 다른 회사 서비스에서 구현된 서비스였다. 프로젝트 팀장님께 해당 서비스에서 관리하는 주소에 대한 규격을 확인해달라고 요구했지만, 정확한 규격을 받을 수 없었다. 연동에는 주소 전체 값만 내려왔다. 스키마를 지정해서 저장하기에는 너무 위험했다. 자칫해서 변경이 된다면 서비스 전체를 갈아엎어야 할 수도 있기 때문이다. 

 

그런 일이 실제로 일어나기도 한다...

 

 고민을 하던 중, DDD 책에서 Attribute Converter에 관한 설명이 기억났었다. 그렇다! 어차피 주소가 내려오는 것은 변함이 없다. 다만, 그것을 서비스에서 어떻게 구현하느냐가 문제였다. 즉, 주소는 주소대로 DB에 저장하되, 서비스의 필요에 따라 변환해서 사용하면 되는 것이었다.

적용 결과

 결론부터 이야기하자면, 서비스 구현에 DB 스키마 눈치를 덜 보게 되었다. 또한 도메인 설계가 보다 폭넓은 방향으로 볼 수 있게 되었다.

 

 회사 서비스 구현에서 DB 형상 관리를 위해 flyway를 사용하고 있었다. 그래서 스키마가 조금이라도 바뀌는 날이라면, 스크립트를 짜서 커밋해야 했다. 서비스 구현만으로도 바쁜 개발 과정에서 DB 스키마까지 관리해야 한다. 구글에 또 mariadb alter table을 검색한다..

 

보라보라한 구글,,,

 Attribute Converter를 적용한 뒤로는 이런 걱정이 많이 줄었다. 정말 큰 틀에서 변경되지 않는 이상 대부분이 코드 레벨에서 대응이 가능했기 때문이다. 그리고 스키마 = 엔티티 객체라는 인식이 깨졌다. 이점에 있어서 도메인 설계가 이전보다 더욱 자유로워졌다. 이게 얼마나 큰 해방감인지는 직접 적용해보면 알 것이다.

 다만, 조금의 부작용도 있다. JpaRepository나 Querydsl로 쿼리 하기가 조금 까다로워졌다. 스키마 = 엔티티일 때는 질의가 필요한 컬럼에 관한 path가 엔티티 속성과 일치해서 바로바로 사용하기 쉬었지만, Attribute Converter를 적용하게 되면 컬럼과 엔티티 속성이 일치하지 않게 되므로 별도의 작업이 필요하다. JpaRespository의 경우는 쿼리 메서드를 사용하지 못했다(내가 방법을 못 찾은 것일 수도 있다).

결론

요즘 DDD 관점에서 설계하려고 많이 노력하고 있다. 이러한 과정에서 DB 스키마는 도메인을 설계하는 것에 가장 큰 축이자 두꺼운 틀이었다. 이 틀을 자유롭게 넘나들면서 설계할 수 있는 방법을 알게 되었다. 도메인 독립 만세다.