Replies: 2 comments
-
1. 객체를 참조하는 경우
-> A 객체의 정보를 가져올 때, 대부분 B 객체의 정보도 함께 가져와야한다면 객체를 참조하는 것이 좋습니다. [예시] 2. id를 참조하는 경우
-> 순환 참조의 위험이 있는 경우, 성능이 중요한 경우 id를 참조하는 것이 좋습니다. [예시] |
Beta Was this translation helpful? Give feedback.
-
|
저는 객체 참조와 ID 참조 중 어느 것이 더 좋은지는 같은 트랜잭션 안에서 함께 변경되고, 함께 정합성을 보장해야 하는 관계라면 객체 참조가 자연스럽고, 1. 두 방식의 본질적 차이저는 이 둘의 차이를 단순히 "필드에 무엇을 담느냐"의 차이가 아니라, 객체 참조 방식 public class Reservation {
private Long id;
private Member member; // Member 객체 자체를 참조
private ReservationTime time;
private Theme theme;
}이 방식은 Reservation이 자신의 일부로 Member를 포함하고 있다는 의미입니다. ID 참조 방식 public class Reservation {
private Long id;
private Long memberId; // Member의 식별자만 보유
private Long timeId;
private Long themeId;
}이 방식은 Reservation이 Member라는 "다른 객체"의 존재만 알고 있다는 의미입니다. 핵심은 객체 참조는 "내 일부", ID 참조는 "내가 알고 있는 다른 존재"라는 관계의 차이를 표현한다는 점이라고 생각합니다. 2. 객체 참조가 적합한 경우저는 두 객체가 같은 일관성 경계 안에서 함께 다뤄져야 할 때 객체 참조가 자연스럽다고 생각합니다. (a) 같은 Aggregate 안에 속할 때 DDD에서 말하는 Aggregate는 함께 생성되고, 함께 변경되며, 예를 들어 public class Order {
private Long id;
private List<OrderLine> orderLines; // 객체 참조
public Money totalPrice() {
return orderLines.stream()
.map(OrderLine::price)
.reduce(Money.ZERO, Money::add);
}
}OrderLine은 Order 없이는 의미가 없습니다. (b) 도메인 로직에서 협력 객체의 행위가 필요할 때 예약 도메인에서 "이 예약이 특정 회원의 것인가?"를 판단하는 로직을 생각해보면, public boolean isOwnedBy(Member member) {
return this.member.equals(member);
}객체 참조가 있으면 도메인 객체끼리 메시지를 주고받으며 자연스럽게 협력할 수 있습니다. ID만 들고 있다면 Service가 (c) 객체 그래프를 따라가는 표현이 도메인 의미를 잘 드러낼 때
3. ID 참조가 적합한 경우반대로 저는 두 객체가 서로 다른 일관성 경계에 속하거나, 함께 변경되지 않을 때 ID 참조가 더 적절하다고 생각합니다. (a) 서로 다른 Aggregate 사이의 관계 DDD에서는 일반적으로 "Aggregate 간에는 ID로 참조하라"는 원칙이 있습니다. 예를 들어 Reservation과 Member의 관계를 생각해보면, 회원 정보 수정과 예약 생성은 별개의 작업입니다. 회원 정보가 바뀐다고 예약이 함께 바뀌어야 할 이유는 없습니다. public class Reservation {
private Long id;
private Long memberId; // Member Aggregate에 대한 참조
private LocalDate date;
}(b) 객체 그래프가 너무 깊어지는 것을 방지하고 싶을 때 객체 참조를 무한정 허용하면 한 객체에서 시작해 전체 도메인을 탐색할 수 있는 거대한 그래프가 만들어집니다. 예를 들어 ID 참조를 사용하면 "여기서부터는 다른 영역"이라는 경계가 명확해집니다. (c) 성능과 영속성 관점에서 함께 로딩될 필요가 없을 때 JPA를 사용한다면 객체 참조는 보통 연관관계 매핑과 묶이고, 잘못 다루면 N+1 문제나 불필요한 즉시 로딩으로 이어질 수 있습니다. 예약 목록을 조회할 때 회원 정보가 꼭 필요하지 않다면, ID만 들고 있다가 필요할 때 별도로 조회하는 편이 더 단순할 수 있습니다. 다만 저는 이 "성능" 관점을 첫 번째 기준으로 두지는 않습니다. 성능은 측정 후 판단할 문제이고, 그 이전에 도메인 경계가 명확한지가 먼저라고 생각합니다. 4. 각 방식의 장단점객체 참조의 장점
객체 참조의 단점
ID 참조의 장점
ID 참조의 단점
5. 미션에서의 판단 기준이번 미션의 예약 도메인을 예로 들어보면, 저는 이렇게 구분할 것 같습니다. 객체 참조가 자연스러운 관계
ID 참조를 고려할 만한 관계
다만 이것도 절대적인 답은 아니고, 도메인 로직에서 판단할 때 던지는 질문들 저는 어느 방식을 선택할지 고민될 때 이런 질문을 던져봅니다.
앞의 두 질문에 "그렇다"라면 같은 Aggregate일 가능성이 높고 객체 참조가 자연스럽습니다. 뒤의 질문에서 협력이 적고 독립적이라면 ID 참조가 더 적절하다고 봅니다. 6. 정리저는 객체 참조와 ID 참조의 선택을 이렇게 정리할 수 있을 것 같습니다.
객체 참조는 같은 일관성 경계 안에서 협력하는 객체들 사이에 어울리고, ID 참조는 서로 다른 Aggregate처럼 독립적인 객체들 사이에 어울린다고 생각합니다. 다만 어느 한쪽이 절대적으로 좋다고 보지는 않습니다. 작은 도메인이라면 모든 것을 객체 참조로 두어도 큰 문제가 없을 수 있고, 도메인이 커질수록 Aggregate 경계를 명확히 하기 위해 ID 참조의 비중이 늘어날 수 있다고 봅니다. 중요한 것은 "관습적으로 다 객체 참조" 또는 "관습적으로 다 ID 참조"가 아니라, 매 관계마다 도메인적으로 어떤 의미를 갖는 관계인지 따져보는 자세라고 생각합니다. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
A라는 객체와 B라는 객체가 있다고 가정해보겠습니다.
두 객체의 정보를 함께 조회하기 위해 다음 두 가지 방식이 있을 것 같습니다.
각 방식은 어떤 상황에서 주로 사용하는지, 그리고 각각의 장단점이 무엇인지 궁금합니다.
Beta Was this translation helpful? Give feedback.
All reactions