• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    해결됨

도메인 객체와 엔티티 객체 분리 시 객체 그래프 탐색 관련 질문

23.07.01 17:58 작성 23.07.01 18:07 수정 조회수 493

0

안녕하세요. 김영한 선생님의 강의를 참 잘 보고 있는 학생입니다.

 

SQL 중심적인 개발의 문제점 편에서, 객체지향 프로그래밍에서 객체는 자유롭게 객체 그래프를 탐색할 수 있어야하지만 SQL로 개발하는 경우에는 처음 실행하는 SQL에 따라 탐색 범위가 결정된다는 문제가 있다고 말씀하셨습니다.

 

그리고 엄격한 도메인 주도 설계의 관점에서는 '도메인 객체'와 '엔티티 객체'를 분리해야 한다고 알고 있습니다. 비즈니스 로직을 다루는 도메인 객체가 JPA라고 하는 기술에 의존하는 것은 영 즐거운 일은 아니기 때문이죠..

( https://stackoverflow.com/questions/24703756/having-separate-domain-model-and-persistence-model-in-ddd )

그렇기 때문에 도메인 객체와 엔티티 객체를 분리하게 된다면 Repository 계층에서 예를 들어 findById를 했을 경우 엔티티 객체를 도메인 객체로 매핑해서 돌려주어야 합니다.

 

그런데 이럴 경우, 기존의 SQL로 개발하는 경우와 비슷한 문제가 발생하게 되는 것 같습니다. 매핑을 어디까지해서 돌려주어야 하느냐는 점이죠.

Member를 조회했을 때, 객체 그래프 안에 있는 Category까지 싹싹 다 조회해와서 매핑을 해주기도 곤란한 노릇이고, MemberWithTeam, MemberWithOrderAndOrderItem... 와 같은 객체를 따로 따로 만드는 것도 요상해보입니다. 그렇다고 객체 그래프를 다 끊어놓자니 그것도 객체지향적이지 않은 것 같아보이구요..

 

이런 상황에서는 어떤 식으로 도메인 객체를 설계하는지, 엔티티 객체의 매핑은 어떤 방법으로 이루어지는지가 너무 궁금합니다.

 

답변 1

답변을 작성해보세요.

1

안녕하세요. Octoping님

모든 아키텍처에는 트레이드 오프가 있습니다.

특히 도메인 객체와 엔티티 객체를 분리하는 것은 매우 큰 트레이드 오프가 있습니다.

장점: 구현을 JPA 대신에 다른 것으로 변경할 때 이점을 얻을 수 있습니다.

단점: JPA가 제공하는 지연로딩을 포함한 수 많은 기능을 사용할 수 없습니다.

이런 트레이드 오프를 생각하고 본인의 프로젝트에 맞는 방법을 적용하는 것이 필요합니다.

제 경험상 대부분의 프로젝트에서 이 둘을 분리하면 얻는 것 보다 잃는 것이 훨씬 많습니다. 특히 생산성 측면에서 비슷한 코드를 계속 작성해야 하고, 또 JPA가 제공하는 수 많은 기능들을 사용할 수 없습니다.

프로젝트에서 엔티티가 아주 단순하고, 구현을 변경해야 할 가능성이 높다면 그때는 분리하는 것의 이점을 얻을 수 있습니다.

도움이 되셨길 바래요.