* 김우근 님의 'Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트' 강의를 보고 작성된 글입니다. 제 견해가 섞여 들어있기 때문에 강사님의 의견과 다를 수 있습니다.
Java + SpringBoot 개발자라면 entity라는 말을 질리도록 들어봤을 것이다. 그런데 강의에서 'Entity는 JPA랑 상관이 없다' 라고 말하길래 한번 정리를 해보고자 한다.
Entity(엔티티)
먼저 우리가 흔히 말하는 엔티티는 다음의 세 가지를 뜻한다고 볼 수 있고, 강의에서는 각 개념들을 모두 구분짓고 있다
Entity
- Domain Entity (도메인 엔티티)
- SW에서 어떤 도메인이나 문제를 해결하기 위해 만들어진 모델
- 비즈니스 로직을 들고 있고, 식별 가능하며, 일반적으로 생명 주기를 갖는다
- 도메인 객체랑 혼용해서 사용되며, 개발에서 주로 얘기하는 엔티티는 Domain Entity를 의미한다고 보면 된다
- 객체 지향 진형에서는 'Class'로 표현한다
- DB Entity (Database 엔티티)
- 데이터베이스에 표현하려고 하는 유형, 무형의 객체(object)를 말한다
- 데이터베이스 진형에서는 'Table'로 표현한다
- Persistence Object (영속성 객체)
- 실제 개발 환경에서는, DB 엔티티 값과 도메인 엔티티의 값이 서로 연결되어야 한다
- 따라서 DB 엔티티에 있는 값(데이터)을 도메인 엔티티(객체)로 매핑해주는 역할을 전담하는 엔티티(매개체)가 필요했고, 이것이 '영속성 객체', 'JPA' 이다
하지만 실제 개발을 할 때, 우리는 세 가지를 구분 지어 사용하지 않는 경우가 많다. 예를 들어 도메인 엔티티(객체)에 @Entity 어노테이션을 달아서 영속성 객체로 사용을 하는 경우를 의미한다.
그렇다면 이렇게 구분하지 않고 사용해도 되는 것일까?
Entity의 구분
강의에서는 도메인 엔티티와 영속성 객체를 웬만하면 구분해야 한다고 주장한다. 따라서 도메인 엔티티(객체)에 JPA 어노테이션이 붙는 것을 반대한다. 이유는 다음과 같다
Entity를 구분지어야 하는 이유
- 도메인에 JPA 엔티티가 붙는 순간, 개발 중인 시스템이 RDB에 종속된다
- ex) RDB가 아닌 MongoDB를 사용한다면, Entity가 아닌 Document를 사용해야 한다
- 또한 DocumentDB에서는 ORM(Object Relational Mapping)이 아닌 ODM(Object Document Mapping)을 사용하기 때문에, RDB에서 파생된 용어들을 사용하는 JPA를 따를 수 없다
- 따라서 도메인에 JPA 엔티티를 붙였는데 MongoDB를 사용해야 하는 순간이 생긴다면 곤란해진다
강의 내용을 정리해 보자면, 'Entity는 JPA랑 상관이 없다' 라는 말은 'Domain Entity는 JPA랑 상관이 없다' 라는 말을 한 것으로 해석할 수 있다. 확장성을 고려해 봤을 때, 이렇게 도메인과 영속성을 구분 지어 사용하는게 확실히 깔끔할 것 같다는 생각이 든다. 그리고 헥사고날 아키텍쳐를 찍먹해본 입장에서, 헥사고날에서는 Domain과 Persistence를 구분지어 사용하기에 결국 강의의 끝이 헥사고날인 이유를 알 것 같은 강의였다.
하지만 헥사고날 아키텍처를 딱 한번! 찍먹해본 입장에서 생각해보면, 레이어드 아키텍처에 비해 코드의 양이 너무나도 많은데다 개발자가 헥사고날 아키텍처에 대한 이해도가 높지 않다면 구현하는 것 자체만으로도 생각할게 너무 많아서 벅차고, 실제로 DB나 클라이언트가 바뀌는 경우가 흔치 않을 것이라 생각해서 헥사고날 아키텍처를 기피하게 되는 것 같다(물론 개발중인 프로젝트에서 바뀌지 않더라도 확장성을 생각했을 때, 모듈화 시켜놓은 코드를 떼어내서 다른 곳에 사용하기에는 헥사고날이 제격일지도..)
어디까지나 이런 생각 또한 내가 아직 실력이 부족해서 그렇게 느끼는 것일 수도 있으니 일단 공부를 더 해봐야겠다.