✔ 참고영상
🚩 Entities und Value Objects
🚩 Aggregate Root Design 101 | DDD, Clean Architecture, .NET 6
Step 1. 개념 정리
1. Domain Model Object
: 특정 도메인 내에서 특정한 책임을 가지고 비즈니스 로직을 수행하는 객체. 모든 도메인 객체는 Entity 또는 VO(Value Object)다.
2. Entity
: 도메인 객체 유형 중 하나로, 변하지 않는 특정 ID를 가지며 가변적(Mutable)이다. 서로 다른 Entity의 ID가 같다면 속성(Attribute)이 달라도 같은 Entity로 판단한다.
<Entity - 예시1>
봉사 동아리 전국 연합회에 Jane Doe라는 사람이 있다고 가정할 때 이 사람의 정보는 아래와 같다.
- MemberId = 123
- Firtst Name = Jane
- Last Name = Doe
- School = Good High-school
- Address = London
만약 Jane이 어떠한 이유로 인해 개명을 하고 이사를 갔다고 가정하면 정보는 아래처럼 변경될 것이다.
- MemberId = 123
- First Name = Mary
- Last Name = Doe
- School = Better High-school
- Address = Edinburgh
이 경우 Jane Doe와 Mary Doe는 같은 사람일까, 다른 사람일까? 당연히 같은 사람이다. 이름을 제외한 모든 정보가 달라졌어도 사람 자체가 같다는 사실은 변하지 않는다.
<Entity - 예시2>
이번에는 동일한 동아리에 같은 학교를 다니는 동명이인 2명이 있다고 가정해보자. 두 사람의 정보는 다음과 같다.
- MemberId = 456
- First Name = John
- Last Name = Doe
- School = Best High-school
- Address = Paris
- MemberId = 789
- First Name = John
- Last Name = Doe
- School = Best High-school
- Address = Paris
이 경우 첫번째 Jonh Doe와 두번째 Jonh Doe는 같은 사람일까? 회원번호를 보면 서로 다른 값을 가지고 있으므로 두 사람은 다른 사람이라는 것을 알 수 있다. 모든 정보가 같아도 다른 사람인 것이다.
❗ 두 예시에서 우리는 두 사람이 같은 사람인지, 다른 사람인지를 판단하기 위해 '회원번호'라는 변하지 않는 고유한 값을 비교했다. 이렇듯 모든 Entity는 불변의 고유한 ID를 가지며, 속성 값에 상관 없이 ID가 일치하면 같은 객체라고 판단한다.
3. VO
: 도메인 객체 유형 중 하나로, ID를 가지고 있지 않으며 불변적(Immutable)이다. 서로 다른 VO의 모든 값(Value)이 같다면 같은 VO로 판단한다. Value Object는 한 번 생성되면 절대로 변하지 않는다. 객체의 속성이 하나라도 값이 바뀌면 새로운 객체를 생성하며 기존 VO는 메모리에서 삭제된다. 이것이 VO가 Immutable한 이유다.
더 알아보기 : DTO vs VO 개념정리
Step 2. 예시를 통한 개념 비교
<예시1>
부동산 거래를 관리하는 애플리케이션(Propetry Management Application)을 만든다고 하자. 이 어플리케이션의 도메인을 설계할 때 필요한 객체는 아래와 같다.
먼저 Prospective-Buyer은 구매 예정자에 관한 객체로, 구매 예정자의 이름(buyerName)과 사는 곳의 주소(address) 등이 저장되어 있다. 만약 객체의 속성(이름, 주소 등)이 바뀐다면 어떨까? 구매 예정자가 거래 과정 도중에 개명을 한다면? 혹은 이사를 간다면? 그래도 구매 예정자 그 자체는 동일한 사람이다.
Property는 판매 중인 부동산에 관한 객체다. 여기에는 부동산 소유주(seller)와 주소(address), 면적(sqft), 방 개수(roomLayout) 등이 저장되어 있다. 만약 소유주가 작은 방 두 개를 합쳐서 큰 방 하나로 만들었다고 하자. 내부 구조가 바뀌었으니 리모델링 전과 후는 다른 집일까? 그렇지 않다. 당연히 같은 집이다.
Purchase는 Prospective-Buyer과 Property 사이에서 거래 정보를 나타내는 객체다. 이 안에는 거래날짜(date), 가격(price)을 포함하여 거래상태(status), 대금 지불 여부(paidInFull), 등기부등본 등록 여부(enteredLandRegister) 등이 저장되어 있다.
이번에도 실제 부동산 거래를 생각해보자. 건물이나 토지를 살 때 계약을 맺고, 대금을 지불하고, 계약을 완료하는 것은 그리 간단한 일이 아니다. 우리는 일정 시간을 두고 복잡한 과정을 거쳐야 한다. 그 과정에서 앞서 말한 변수들은 계속해서 상태가 변할 것이다.
예컨대 계약 성사 시점에 status = "Reserved"고 paidInFull = False지만, 계약 완료 시점에는 status = "Completed"로, paidInFull = True로 바뀐다. 그렇다고 상태가 변할 때마다 구매자와 부동산 사이에 체결된 거래가 새로운 거래로 갱신될까? 그럴 리 없다.
우리는 예시를 통해 세 가지 객체의 값이 변경되어도 해당 객체 자체는 변하지 않는다는 것을 확인했다. '값이 변경돼도 여전히 같은 객체'라는 것은 그 객체가 Entity라는 증거다. 즉, Prospective-Buyer, Property, Purchase 모두 Entity다.
<예시2>
그렇다면 이런 경우에는 어떨까? 애플리케이션에 구매자의 주소를 추적하여 송장을 보내는 기능을 추가하고자 한다. 이 기능을 구현하기 위해 Address 객체를 따로 만든다고 하면 이 Address 객체는 Entity일까? 다시 말해, 값이 바뀌어도 같은 객체라고 할 수 있을까?
이번에도 예시를 들어보자. Frank라는 사람이 있다. Frank는 계약서를 작성하고, 대금을 모두 지불했으며, 마지막 단계인 등기부등본 등록만 남겨놓고 있다. 그는 매매 계약서에 자신이 사는 주소를 Beuelsweg 13 in 50733 Cologne로 작성하였으므로 시스템 상에서 그의 주소는 이 값으로 초기화 된다.
만약 계약이 완료되기 전에 Frank가 이사를 간다면 어떨까? 그의 주소 객체 값은 새로 이사간 집의 주소는 Am Falder 22 in 40589 Dusseldorf로 바뀔 것이다. 그렇다면 이사 가기 전의 집과 이사간 후의 집은 같은 집일까, 다른 집일까? 답은 쉽다. 다른 집이다.
값이 달라지니 객체도 다르다. Address는 Entity가 아닌 Value Object가 되는 것이다.
Step 3. 개념 확장
우리는 예시를 통해 Entity 와 Value Object를 알아보았다. Entity는 속성 값이 바뀌어도 여전히 같은 객체이며, VO는 속성 값이 바뀌면 전혀 다른 객체가 된다.
여기서 한 가지 질문을 던질 수 있다. 한 번 Entity라고 판단된 객체는 항상 Entity일까? 우리가 Value Object라고 판단한 Address 객체는 다른 시스템에서도 Value Object로 사용될까?
결론부터 말하자면 아니다. Address 객체도 경우에 따라서는 Enity가 될 수 있다.
<예시3>
이번에는 네비게이션 시스템을 설계하고 구현한다고 해보자. 이때 Address 객체는 예시2와 마찬가지로 도로명(street), 우편번호(zipCode) 등과 같은 변수를 가질 것이다.
예시2와 동일하게 'Beuelsweg 13 in 50733 Cologne'라는 주소를 가진 건물이 있다고 할 때, 주소 정책으로 인해 도로명이 바뀌었다고 가정하자. 'Beuelsweg'였던 도로명이 'Am Falder'로 변경된다면 'Beuelsweg 13 in 50733 Cologne'와 'Am Falder 13 in 50733 Cologne'는 서로 다른 건물일까?
이 경우엔 값이 바뀌었음에도 객체가 달라지지 않았다. 여기서 Address는 VO가 아닌 Entity인 것이다.
✍ 결론
예시2의 Address와 예시3의 Address는 똑같은 변수를 가지고 건물의 주소를 나타내지만, 하나는 VO고 다른 하나는 Entity다. 그 이유는 맥락(Context)이 다르기 때문이다. 전자는 '사람이 사는 곳이 달라졌기 때문에' 주소 값이 변경되었고, 후자는 '도로의 명칭이 달라졌기 때문에' 주소 값이 변경됐다. 결론만 보면 비슷해 보이지만 실상 전혀 다른 얘기다.
앞서 말했듯 Entity와 Value Object는 Domain에서 사용하는 Object다. 이는 개발자들이 도메인 객체를 설계하고 관리하기 쉽게 만들기 위해 사용하는 개념으로, 프로그램은 해당 객체가 Entity인지 VO인지 알 수도 없고 알 필요도 없다.
Entity와 VO를 나누는 것은 어디까지나 개발자의 몫이다. 그러니 무엇보다도 중요한 건 해당 객체가 어떤 역할을 하고, 어떤 맥락에서 사용되는지 파악하는 것이다.
