Clean Spring ‐ JPA and Domain Model Patterns - thought-corner/backend-roadmap GitHub Wiki

JPA 모델과 도메인 모델은 다른지?

  • 도메인 모델은 DB와 매핑되는 데이터 모델과는 다르며 이를 분리해야 한다.
    • 어댑터 계층에 JPA 엔티티 등의 모델을 따로 만들고
    • Repository를 구현한 어댑터를 이용해 도메인 오브젝트와 JPA 오브젝트를 매핑해준다.
    • Member 외에 MemberEntity 클래스를 만들어 JPA 관련 설정을 모두 이곳으로 옮긴다.
    • MemberRepository를 구현한 MemberRepositoryJpaAdapter에서 이 2가지 오브젝트를 서로 매핑해주는 코드를 작성한다.

위와 같은 접근 방법을 선호하는 이유

  • 데이터 모델과 도메인 모델이 너무 다른 경우 - 레거시 DB에 도메인 모델 설계를 적용해야 하는 경우
  • 복잡한 도메인 모델이 데이터 모델과 간단하게 매핑되지 않는 경우 - JPA 모델과는 다른 도메인 모델이 존재한다면
  • 데이터 저장 기술이 바뀌는 경우
  • 코드에 등장하는 JPA 어노테이션이 기술 의존적 - 이런 어노테이션이 코드 실행에 어떤 영향을 주는지
  • 도메인 코드에 관심사가 다른 JPA 매핑 어노테이션, DB 정보가 포함되기에 - 가독성 또는 취향

JPA 기술의 정체성

  • ORM : 패러다임이 다른 관계형 DB와 객체지향 모델의 불일치를 해결하는 기술이다. SQL 매핑과는 다르다.
  • JPA의 기술적 목표는 자바 애플리케이션 개발자가 관계형 데이터베이스를 관리하기 위해 자바 도메인 모델을 활용할 수 있는 객체/관계 매핑 기능을 제공하는 것이다.
  • 결국 JPA의 엔티티는 경량 영속 도메인 오브젝트이다.

도메인 모델 패턴

  • 단순 도메인 모델은 테이블과 클래스가 1 : 1로 매핑된다.
  • 복잡한 도메인 모델의 경우 DB 매핑이 어렵다는 문제가 있다. 이걸 해결해주는 것이 바로 JPA이다.
  • JPA가 매핑을 통해서 해결하려는 패러다임 불일치 문제는 다음과 같다.
    • 세분성 불일치(Granularity)
    • 상속 불일치(Subtype)
    • 정체성 불일치(Identity)
    • 연관 불일치(Association)
    • 데이터 탐색 불일치(Navigation)

Spring Data

  • 다양한 데이터 저장소에 대한 데이터 접근을 단순하고 일관된 프로그래밍 모델로 제공한다.
    • 일관된 프로그래밍 모델 : 저장소의 종류와 상관없이 동일한 방식으로 데이터에 접근하도록 한다.
    • 보일러 플레이트 코드 감소
    • 데이터 저장소 특성 유지
    • 확장성과 유연성
  • Repository<T, ID> : T : 도메인 타입 = 엔티티 = 애그리거트 루트

도메인 모델과 JPA 모델을 반드시 분리해야 한다는 주장에 대한 반박 정리

  • 대부분 데이터 모델과 도메인 모델은 다르지 않다.
  • 복잡한 도메인 모델의 매핑은 JPA가 충분히 지원한다.
  • 모델 변환 로직과 유사한 2가지 클래스로 인한 불필요한 복잡성이 증가한다.
  • JPA는 근본적으로 도메인 오브젝트의 매핑을 위해서 설계된 기술이다.
  • JPA는 도메인 계층을 침범하지 않는다.
  • 복잡한 쿼리 로직은 커스텀 리포지토리와 어댑터 구현을 통해서 충분히 개발 가능하다.
  • 도메인 계층과 데이터 계층의 결합은 불가피하다. 이 둘이 완전히 독립적인 경우는 매우 드물다.

성급한 분리는 오히려 복잡성만 초래할 뿐이고 JPA는 도메인 모델 중심의 개발을 충분히 잘 지원하고 있다.

Add a custom footer
⚠️ **GitHub.com Fallback** ⚠️