DDD의 Entity와 JPA의 Entity를 구분해야하는 것인가?

DDD Entity와 JPA Entity 구분의 고민

 

EATceed 프로젝트에서는 JPA의 Entity와 도메인 주도 설계(DDD)의 Entity를 구분하여 코드를 작성하고 있습니다. 하지만, 몇몇 JPA 엔티티와 DDD 엔티티들이 구조적으로 거의 흡사하여, 이 둘을 구분하는 것이 옳은 선택인지 고민이 생겼습니다.

제가 생각하는 장점과 단점은 아래와 같습니다.

장점

1. 명확한 책임 분리
   DDD Entity는 비즈니스 로직과 도메인 모델링에 집중하고, JPA Entity는 데이터베이스와의 매핑에만 집중하게 되어 각 클래스의 책임이 명확해집니다. 이를 통해 코드를 더 이해하기 쉽고 유지보수하기 용이하게 만듭니다.
2. 도메인 모델의 순수성 유지
   DDD Entity는 데이터베이스에 의존하지 않고, 순수한 도메인 로직만을 포함하게 됩니다. 이는 도메인 모델이 JPA와 같은 특정 기술에 종속되지 않도록 하여, 기술 변화나 데이터베이스 교체 시 더 유연한 대응이 가능합니다.

단점

1. 코드 복잡성 증가
   DDD Entity와 JPA Entity를 분리하면, 두 개의 엔티티 간에 데이터를 변환하거나 동기화하는 코드가 추가로 필요해져 코드의 복잡성이 증가할 수 있습니다. 이로 인해 개발자들의 부담이 늘어날 수 있습니다.
2. 개발 생산성 저하
   DDD Entity와 JPA Entity를 각각 관리해야 하므로, 개발자가 코드 작성 시 더 많은 작업이 필요하게 됩니다. 이는 코드 작성과 유지보수에 드는 시간이 늘어날 수 있습니다.
3. 메모리 및 성능 비용 증가
   두 개의 객체를 따로 유지하고 관리하는 과정에서 메모리 사용량이 증가할 수 있으며, 두 객체 간의 변환 작업에서 성능 저하가 발생할 가능성이 있습니다.

결정을 하기 전, DDD의 Entity와 JPA Entity에 대해서 알아보겠습니다.

 

DDD의 Entity와 JPA의 Entity는 다르다.

 

DDD의 Entity와 JPA의 Entity는 다릅니다.

 

DDD에서의 Entity는 비즈니스를 도메인 관점에서 문제를 해결하기 위한 객체이고, JPA에서의 Entity는 Java 객체를 데이터베이스 테이블에 매핑하기 위해 사용되는 객체입니다.

 

클린 아키텍처에서

 

From an architectural point of view, thedatabase is a non-entity—it is a detail that does not rise to the level of an architectural element. Its relationship to the architecture of a software system is rather like the relationship of a doorknob to the architecture of your home.

건축적 관점에서 볼 때, 데이터베이스는 비실체적인 존재로, 건축 요소의 수준에 도달하지 않는 세부사항에 불과하다. 소프트웨어 시스템의 아키텍처와의 관계는 집의 건축 구조와 문손잡이의 관계와 유사하다.

데이터베이스는 DDD의 엔티티(= 비즈니스를 도메인 관점에서 문제를 해결하기 위한 객체)가 아니다.

 

즉, ORM 기술의 스팩인 JPA 역시 세부사항입니다.

 

Stack Over Flow 에서

 

일반적으로, DDD의 엔티티와 값 객체는 ORM 엔티티와 값 객체와 일부 유사점이 있지만, 매우 다른 개념입니다. 두 가지 주요 이유는 다음과 같습니다

1. 두 개념에서 말하는 "아이덴티티"는 다릅니다. 데이터베이스의 아이덴티티는 비즈니스와 관련된 아이덴티티와 거의 일치하지 않으며, 특히 비정규화된 경우에 그렇습니다.
2. ORM과 영속성(Persistence)은 기술적인 문제이지 "비즈니스"와는 관련이 없습니다.
   
   

DDD 엔티티와 값 객체는 데이터가 아닌 객체입니다. 이는 일반적으로 객체 지향 원칙을 준수해야 한다는 것을 의미하며, 그 중 하나는 객체가 데이터가 아닌 행동에 초점을 맞춰야 한다는 것입니다. 이는 이들에 대해 완전히 다른 힘이 작용하게 만듭니다.

이러한 점들 때문에, 그리고 다른 이유가 있을 수도 있지만, ORM은 "진정한" 비즈니스 객체와 섞여서는 안 됩니다.

DDD Entity in orm and java

DDD Entity in orm and java

 

DDD_START! 도메인 주도 설계에서

2장에서 아래와 같은 말이 나옵니다.

신입 시절에 처음 도메인 모델을 만들 때 DB 테이블의 엔티티와 도메인 모델의 엔티티를 구분하지 못 해 거의 동일하게 만들곤 했다.

도메인 모델의 엔티티와 DB 모델의 엔티티를 같은 것으로 생각해서 그랬는데 경력을 더할 수록 도메인 모델에 대한 이해가 쌓이면서 실제 도메인 모델의 엔티티와 DB 관계형 모델의 엔티티가 같은 것이 아님을 알게 되었다.

두 모델의 차이점은 도메인 모델의 엔티티는 데이터와 함께 도메인 기능을 함께 제공한다는 점이다.

또한, 도메인 모델의 엔티티는 두 개 이상의 데이터가 개념적으로 하나인 경우 밸류 타입을 이용해서 표현할 수 있다는 것이다.

 

 

확실히 JPA Entity와 DDD에서 말하는 Entity는 다르다는 것을 알 수 있었습니다.

 

 

그렇다면, 내 상황에서는 어떻게 해야할까?

 

여러 JPA 엔티티들이 구조적으로 거의 동일하다 보니, 굳이 분리하지 않고 하나의 JPA 엔티티를 DDD에서 말하는 엔티티처럼 사용하는 것이 맞다고 생각했습니다. 그러나 여전히 이 접근 방식에 대해 확신이 서지 않았습니다.

이런 저런 고민을 하며 구글링을 하고 있던 와중  저와 비슷한 고민에 대한 "김영한님의 답변"을 발견하습니다.

 

엔티티와 도메인 객체를 따로 분리하지 말고, 엔티티 자체를 도메인 객체로 사용하시는 것이 좋습니다. xml로 매핑하면 정말 겉으로 보기에는 순수한, 의존성 없는 코드를 얻으실 수 있겠지만, 애노테이션 정도는 실용적인 관점에서 가지고 가는 것이지요.

https://www.inflearn.com/community/questions/90087/domain과-repository-구현-상세를-분리하고자-할-때-entity-디자인

domain과 repository 구현 상세를 분리하고자 할 때 ... - 인프런 | 커뮤니티 질문&답변

다음은 "최범균님의 답변"입니다.

 

우선 개인적으로는 너무 완벽하게 JPA에 대한 의존을 제거하려고 노력하지 않아도 된다고 생각합니다. 큰 틀에서 구조를 깨뜨리지 않는 선에서 JPA에 의존하는 정도는 허용해도 괜찮다고 봅니다.

 

https://www.inflearn.com/community/questions/946595/%EB%8F%84%EB%A9%94%EC%9D%B8%EA%B3%BC-jpa-%EC%97%94%ED%8B%B0%ED%8B%B0

도메인과 JPA 엔티티 - 인프런 | 커뮤니티 질문&답변

 

 

위 글을 읽고 아래와 같은 결론을 얻었습니다.

 

구조적으로 JPA Entity와 동일한 Entity들은 굳이 분리하지 말고, JPA Entity를 DDD에서 말하는 Entity처럼 사용하자.