어떤 경우 도메인(개념)객체를, 어떤 경우 JPA 엔티티를 활용하... - 인프런

제미니의 개발실무 - 커머스 백엔드 기본편

요구사항 느끼기

어떤 경우 도메인(개념)객체를, 어떤 경우 JPA 엔티티를 활용하나요?

작성

서비스들을 보면 어떤 경우는 finder같은 서비스 하위 계층을 통해 도메인(개념)객체를 활용하기도 하고, 서비스에서 직접 repository를 의존해서 jpa entity를 활용해서 로직을 수행하는 케이스도 있어 보입니다!

혹시 서비스 단에서 도메인 객체를 가져와서 사용하는 것과 jpa entity를 직접 활용하는 것의 판단 기준이 따로 있으실까요?

kotlin spring-boot 도메인 dbms/rdbms backend

답변 3

제미니

지식공유자

안녕하세요! 질문 감사합니다!

사실 강의에서 언급하였지만 일부로 큰 혼란을 느끼시라고 구현 패턴을 다양하게 넣어두었습니다 😄
판단 기준은 회사마다 팀마다 전략이 다를 수 있는 부분이라서 정답이 있는 것은 아닙니다!

그럼에도 제 판단 기준을 말씀드리면 저는 회사/팀의 역량 수준이 중요한 판단 기준입니다

같이 일하는 동료들의 역량이 조금 아쉽다면, 약간의 경직 된 룰을 만들어서 팀을 유도합니다
(경직 된 룰 = 무조건 Finder 같은 도구를 만들어서 처리하자)

* 물론 이 수준을 영원히 유지하지 않습니다 팀원들이 어느정도 도메인에 익숙해지고, 구현에 익숙해진다면 좀 더 유연한 룰로 변경해나가는 것을 진행하는편입니다.

만약 베스트 팀이라면 제 경우는 소프트웨어가 성장하는 시점에 맞추어서 성장시키는 것을 선호하기 때문에 굳이 과하게 만드는 방향으론 개발을 하지 않습니다
(다만 제 커리어상으로도 회사에서 이렇게 할 수 있는 팀을 만난 것은 딱 한번 정도 같습니다 ;ㅁ; 현실적으로 어렵습니다......)

그럼으로 repository 를 그냥 직접 쓰게하기도 하죠
(애초에 베스트 팀원들 상황이라면 서로 알아서 잘 할것이기 때문에 걱정 자체가 없습니다ㅎㅎ..)

종합적으로 보면 정해진 것은 없고 강의 예제에서는 일부로 혼란을 느끼시도록 유도했습니다ㅎㅎ
그러므로 직접 코드를 느껴보시면서 어떤 전략이 더 유효 할지 어떨때 저 전략을 써야할지 고민해보시는게 더 중요할 것 같습니다! 😄

모쪼록 답이 되었길 바랍니다! 감사합니다!

우으어으

질문자

현재 구현 상황

쿠폰 선물 서비스를 만들고 있는데 역할을 아래와 같이 나눠봤습니다.

Entity: JPA 영속성 관리, 상태 변경 메서드 (markAsXXX)

Domain: 순수 비즈니스 로직, 판단 메서드 (canXXX, isXXX)

Validator: Domain 객체로 비즈니스 규칙 검증

GiftManager: Gift 생성하고 StateManager 호출

StateManager: Coupon 상태 변경하고 History 기록

코드는 아래와 같이 작성했습니다 (CouponGiftService.class)

public Long sendCouponAsGift(
UUID couponId,
 GiftSender sender,
  GiftRecipient recipient
) { 

// 1. JPA Entity 조회하고 Domain으로 변환 
Coupon coupon = couponRepository.findById(couponId) .orElseThrow() .toDomain();

// 2. Domain으로 비즈니스 검증
couponGiftValidator.validate(coupon, sender, recipient, sentAt);

// 3. GiftManager로 선물 생성 (여기서 재조회 발생)
return couponGiftManager.createGift(coupon, sender, recipient).getId();

문제 상황

Entity를 Domain으로 변환한 다음에 다시 조회하게 되는 상황이 생겼습니다..!

StateManager에서 쿠폰의 상태를 변경할 때 더티체킹을 하려면 jpa 객체가 필요한데, 이를 위해 레포지터리로 재조회를 했습니다

Coupon entity = repository.findById(couponId); // JPA 더티체킹 쓰려고 다시 조회 
entity.updateStatus(...);

질문1. 이럴 땐 어떻게 하는 게 좋을까요?

1. toDomain 하기 전에 JPA 엔티티를 StateManager에 넘긴다

2. StateManager에서 조회 쿼리 1번 더 나가는 건 감수한다

3. JPA 더티체킹 안쓰고 update querydsl 직접 작성한다

4. 애초에 역할 분리를 잘못해서 이런 문제가 생긴 거다

이렇게 4가지 정도 생각해봤는데 어떻게 생각하시나요?

질문2 Domain 객체를 어디까지 활용해야 할까요?

1. 검증만 Domain 쓰고 나머지는 Entity (지금 방식)

2. 모든 로직을 Domain으로 하고 Entity는 영속화만

3. Service 안에서 Domain이랑 Entity 명확하게 분리

Domain 중심 설계랑 JPA 영속성 관리의 균형을 어떻게 잡는지와 비즈니스 로직 중앙화랑 성능이나 영속성 관리 사이에서 트레이드오프를 어떻게 보시는지 의견이 궁금합니다..!

제가 유연하게 상황에 맞게 구현하려하기 보단 어떤 규칙을 세우고 일관적으로 구현해보려 해서 이런 상황이 생기는 거 같기도 하네요 ㅠㅠ..

이런 형태의 구현을 처음 해봐서 의견 남겨주시면 큰 도움 될 거 같습니다..!

우으어으

질문자

감사합니다 직접 제 코드에 적용해보면서 확인해보겠습니다!!

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. 우으어으님.

도메인 객체와 JPA 엔티티의 선택은 소프트웨어 설계와 관련된 중요한 결정 중 하나입니다. 일반적으로 도메인 객체와 JPA 엔티티는 서로 다른 목적을 가지고 있으며, 이 둘을 어떻게 활용할지는 프로젝트의 전체 아키텍처와 요구사항에 달려 있습니다.

도메인 객체 vs JPA 엔티티

도메인 객체(Domain Object):
- 역할: 주로 비즈니스 로직을 담고 있으며, 시스템의 도메인을 표현하는 데 집중합니다.
- 사용 위치: 비즈니스 로직이 복잡하거나 변경 가능성이 높은 경우 사용합니다. 이는 애플리케이션의 다양한 부분에서 동일한 도메인 로직을 재사용할 수 있도록 해줍니다.
- 장점: 높은 응집도를 유지하며, 비즈니스 규칙과 로직을 명확히 주고받을 수 있습니다.
JPA 엔티티(JPA Entity):
- 역할: 데이터베이스와 직접적으로 매핑되는 객체로, 주로 데이터 저장, 조회 등을 담당합니다.
- 사용 위치: 데이터 저장소 접근이 주요 관심사인 레이어에서 주로 사용됩니다. 이는 데이터베이스 스키마와 일치하도록 설계됩니다.
- 장점: 데이터베이스 접근에 최적화되어 있으며, SQL 실행에 최적화된 구조입니다.

선택의 기준

비즈니스 로직의 복잡도: 비즈니스 로직이 복잡하고 여러 곳에서 재사용되어야 한다면, 도메인 객체를 통해 해당 로직을 캡슐화하는 것이 좋습니다.
데이터베이스 접근: 데이터베이스에 관련된 작업이 주된 목적이라면 JPA 엔티티를 직접 활용하여 데이터베이스와의 상호작용을 단순화할 수 있습니다.
변경 가능성: 도메인의 요구사항이 자주 변경된다면, 개념 객체를 독립적으로 관리함으로써 변화에 더 잘 대처할 수 있습니다.

위의 설명을 바탕으로 프로젝트의 요구사항과 현재 설계 상태에 따라 적절한 접근 방식을 선택하는 것이 중요합니다.

관련된 게시물에서 추가적인 인사이트를 얻을 수 있습니다. 다음 링크를 참고하시면 보다 구체적인 사례를 통해 이해를 넓히실 수 있습니다:

도메인 계층에서 Page 사용 질문 - 도메인 계층 설계에 관한 토론을 통해, 어떻게 서로 다른 계층 간의 의존성을 조율할 수 있는지에 대해 더 깊은 이해를 얻을 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변

어떤 경우 도메인(개념)객체를, 어떤 경우 JPA 엔티티를 활용하나요?

도메인 객체 vs JPA 엔티티

선택의 기준