DDD Entity와 Value Object 차이는 DDD를 처음 배울 때 가장 자주 막히는 지점입니다. 둘 다 클래스로 만들 수 있고 둘 다 필드를 가질 수 있기 때문에, 코드 모양만 보면 구분이 잘 되지 않습니다.
핵심은 이 객체를 식별자로 추적해야 하는지, 아니면 값 자체로 비교해도 되는지입니다. 이 질문이 정리되면 Entity와 Value Object는 문법이 아니라 모델링 선택으로 보이기 시작합니다.
DDD Entity와 Value Object를 가르는 질문
Entity는 식별자가 중요한 객체
Entity는 시간이 지나도 같은 대상으로 추적되어야 하는 객체입니다. 예를 들어 주문은 배송지가 바뀌거나 상태가 바뀌어도 같은 주문입니다. 주문 번호나 ID가 같다면 내부 값 일부가 달라도 같은 주문으로 봅니다.
그래서 Entity에서는 식별자와 생명주기가 중요합니다. 생성되고, 상태가 바뀌고, 취소되거나 완료되는 흐름이 도메인 의미를 가집니다. 단순히 필드 값이 같다고 해서 같은 Entity라고 판단하면 안 됩니다.
Value Object는 값이 의미를 만든다
Value Object는 식별자보다 값 자체가 중요합니다. Martin Fowler는 Value Object를 개념적 식별자가 없고 속성 값으로 비교되는 객체라고 설명합니다. 예를 들어 돈, 주소, 기간, 좌표 같은 값은 보통 값이 같으면 같은 의미로 볼 수 있습니다.
Value Object는 가능하면 불변으로 두는 편이 안전합니다. 금액 10,000원이 갑자기 내부에서 12,000원으로 바뀌면 추적이 어렵습니다. 대신 새 금액 객체를 만들어 교체하면 값의 의미가 명확해집니다.
주문 예제로 나누어 보기
class Order {
private final OrderId id;
private Money totalPrice;
private Address shippingAddress;
private OrderStatus status;
}
record Money(long amount, String currency) {}
record Address(String zipCode, String line1, String line2) {}이 예시에서 Order는 Entity에 가깝습니다. 같은 주문 ID를 가진 주문은 상태가 바뀌어도 계속 같은 주문으로 추적되어야 합니다. 반면 Money와 Address는 Value Object에 가깝습니다. 값 조합이 의미를 만들고, 값이 바뀌면 새 값으로 교체하는 편이 자연스럽습니다.
헷갈릴 때 던질 질문
- 값이 완전히 같아도 서로 다른 대상으로 봐야 한다면 Entity일 가능성이 높다.
- 식별자 없이 값만으로 비교해도 도메인 의미가 충분하면 Value Object일 가능성이 높다.
- 상태 변화 이력과 생명주기가 중요하면 Entity 쪽을 의심한다.
- 불변으로 만들어도 자연스럽고 부작용이 줄어들면 Value Object로 보기 쉽다.
무조건 작은 클래스를 Value Object로 만들면 될까
그렇지는 않습니다. Value Object를 너무 많이 만들면 코드가 과하게 쪼개지고, 팀원이 모델을 읽는 비용이 커질 수 있습니다. 반대로 모든 것을 Entity로 만들면 식별자와 변경 추적이 불필요하게 늘어납니다.
좋은 기준은 도메인 언어입니다. 현업 대화에서 “이 값 조합이 하나의 개념으로 자주 등장하는가”, “검증 규칙이 함께 움직이는가”, “잘못 바뀌면 의미가 깨지는가”를 보면 Value Object 후보를 찾기 쉽습니다. 모델 경계를 더 큰 서비스 경계와 연결해 보고 싶다면 MSA 도입 기준 글도 함께 참고할 만합니다.
JPA Entity와 DDD Entity를 섞어 보지 않기
실무에서 자주 생기는 혼동은 JPA의 @Entity와 DDD Entity를 같은 말처럼 쓰는 것입니다. JPA Entity는 ORM 매핑 대상이라는 기술적 의미가 강하고, DDD Entity는 도메인에서 식별자와 생명주기를 가진 객체라는 모델링 의미가 강합니다. 둘이 겹치는 경우는 많지만 항상 같은 것은 아닙니다.
예를 들어 단순 조회용 테이블 매핑 객체는 JPA Entity일 수 있지만 도메인 행위를 가진 DDD Entity로 보기에는 약할 수 있습니다. 반대로 도메인에서 중요한 Entity라도 저장 방식에 따라 여러 테이블이나 문서로 나뉘어 저장될 수 있습니다. 그래서 기술 어노테이션보다 도메인 질문을 먼저 던지는 습관이 필요합니다.
Value Object를 만들면 좋은 신호
- 여러 Entity에서 같은 값 조합이 반복된다.
- 값의 유효성 검사가 항상 함께 움직인다.
- 값이 바뀌면 기존 객체를 수정하기보다 새 값으로 교체하는 편이 자연스럽다.
- 도메인 대화에서 그 값 조합을 하나의 이름으로 부른다.
- primitive 타입 여러 개가 메서드 인자로 계속 함께 전달된다.
예를 들어 금액과 통화, 날짜 범위의 시작일과 종료일, 좌표의 위도와 경도처럼 같이 움직여야 의미가 유지되는 값은 Value Object 후보입니다. 이렇게 묶으면 검증 규칙이 흩어지지 않고, 잘못된 조합을 만들 가능성도 줄어듭니다.
정리
DDD Entity와 Value Object 차이는 클래스 크기나 테이블 유무로 결정되지 않습니다. 같은 대상으로 계속 추적해야 하면 Entity, 값 자체가 의미이고 값이 같으면 같은 것으로 보아도 되면 Value Object입니다. 이 기준을 먼저 세우면 도메인 모델이 훨씬 읽기 쉬워집니다.
