해당 글은 https://www.culttt.com/2014/04/30/difference-entities-value-objects/ 에 대한 번역입니다.
개발을 하다보면 Value Object라는 용어를 듣게 된다. DDD에서 VO는 중요한 개념이다.
하지만 해당 글에서는 어렵게 다루지 않고 순수 VO에 대해서 다루니 걱정하지 않아도 된다. 이 글을 읽고 DDD를 이해하는데 도움이 되기를 바란다.
Entities vs Value Objects
객체 지향 프로그래밍에서 우리는 속성과 메서드를 객체로 표현한다.
예를 들어 사람은 객체로 표현할 수 있다. 사람이라는 객체는 이름, 이메일 주소, 비밀번호 등 다양한 속성을 갖고 있을 수 있다. DB에서 이 사람은 id로 표현된다. 이 말은 즉슨 사람의 속성이 바뀐다 하더라도 같은 객체임을 보장받는다는 것이다. 우리는 이러한 객체를 Entity라고 부른다. Entity는 변할 수 있다, identity를 변경하지 않고 속성들을 바꿀 수 있기 때문이다. id 값이 있기 때문에 Entity 객체는 identity를 유지할 것이다.
우리 애플리케이션에서 사람의 현재 위치를 추적하는 기능이 있다고 가정하자. 사람이 애플리케이션에 성공적으로 연결된다면 새로운 Location이 생길 것이다. Location은 생성되고 없어질 때까지 속성값인 위도와 경도가 절대 변하지 않는다. 속성값이 변할 수 없다면 우리는 불변이라 한다.
또 다른 중요한 구별점은 VO는 identity를 통해서 동등성을 보장받지 않는다는 것이다. 예를 들어 두 Location을 생성했는데 위도와 경도가 동일하다면 두 Location은 동등한 객체이다. 반면에 사람은 속성값이 전부 동일하더라도 같은 사람이 아닐 수도 있다. Entity는 id를 통해서 표현되어진다.
How to Identify Value Objects?
일반적으로 우리는 Entity와 VO를 id 값을 통해서 분리할 수 있다.
Entity의 속성값은 변할 수 있다. 하지만 우리 시스템에서는 동일한 표현으로 사용된다 왜냐하면 유일한 identifier가 있기 때문이다. 반면에 VO는 생성되고 파괴되는 객체의 single 인스턴스이다. 우리는 VO의 특정 instance인지 관심 없고, 속성값을 변경할 수 없다.
그러면 언제 Entity를 쓰고 언제 VO를 써야하는지 알 수 있는가? 애플리케이션에서의 맥락이 결정을 하는 것이다.
아까 예시로 들었던 Location이 위치기반 체크인 앱이라고 생각해보자. 같은 위치라고 해도 identifer를 통해 구분되어질 필요가 생긴다. 그렇다면 이제는 Location이 VO가 아니라 Entity로 쓰여야한다.
우리가 발전소 울타리 CCTV의 관리자라고 생각해보자. 그렇다면 울타리의 위치는 우리에게 중요한 정보가 된다, 어느 위치가 녹화되고 있고, 의심스러운 사람이 어느 울타리 근처에 있는지가 중요해진다. 반대로 어떤 사람이 접근하는지는 관심이 없다. 이런 경우에는 Location이 Entity고, 사람이 VO가 되는 것이다.
그러므로 해당 객체가 Entity인지 VO인지는 애플리케이션의 맥락에 따라서 달라진다. 일반적으로 위치, 날짜, 숫자, 돈 등은 VO로 사용되고 사람들,제품들, 파일들 등은 거의 항상 Entity로 사용된다.
Why is the distinction between Value Objects and Entity Objects important?
왜 VO랑 Entity를 구분짓는게 중요한가?
실제로 몇가지 이유 때문에 구분하는게 중요하긴 하다.
첫째로, 동일한 속성들을 가진 두 entity가 있다고 하면 다른 식별값을 갖고 있기 때문에 두 객체는 다르다. 하지만 동일한 속성들을 가진 두 VO가 있다면 두 객체는 동일하고 자유롭게 바꿔서 사용할 수 있다. 만약 다른 객체를 대체해서 사용할 수 있다면 해당 객체는 VO다. Entities 끼리 교환하게 되면 원치않는 부작용이 생기기 때문에 바꿀 수 없다.
둘째로, 시간이 지나면 Entity의 properties가 변할 것이다 하지만 같은 Entity로 남아있는다. 사용자가 이메일을 변경해도 그대로 있는 것 처럼. 하지만 VO의 속성을 변경해야하면 우리는 객체를 통째로 파괴하고 새로운 객체가 대체해야 할 것이다. 예를 들어 계산을 하면 내가 지불한 금액을 수정해서 돌려받는 것이 아니라, 새로운 낮은 값의 돈 객체를 받게된다.
Conclusion
DDD에서 현실에서의 개념을 애플리케이션에 적용하기 위해서는 Entities 와 VO의 차이를 이해하는 것은 중요하다.
언제 Entity로 써야하고, 언제 VO로 써야하는지 구분하기 위해서 애플리케이션의 맥락을 이해하고 있는 것이 굉장히 중요하다. 한 눈에 봤을 때 식별값이 필요한 것 같아서 Entity로 구현하면 안된다. 불변성이 필요한 객체인데 Entity로 구현을 하게 된다면 원치않는 부작용들이 있을 것이다.
불변 객체는 애플리케이션의 내재된 구조를 보여주기에 중요한 부분이다. 돈 같은 것을 VO로 구현하게 된다면 객체의 상태를 바꾸려다 문제가 생기지 않았다는 것을 보장해주게된다.
항상 명확하게 VO와 Entity를 구분지을 수 있는 것은 아니다, 그래서 애플리케이션의 맥락을 이해하는 것이 요구된다. 하지만 구분을 짓는 것은 중요하다, 그리고 현실 세계를 애플리케이션으로 표현할 때 주의해야하는 부분이다.
그럼 지하철 경로에서는 VO와 Entity를 어떻게 구분지어야 할까?
먼저 Station은 VO다. 이름은 유일하고 이름이 같은데 다른 객체는 존재하지 않아야 한다.
Line은 Entity다. 이름과 색은 유일하므로 다르겠지만 모든 속성값이 수정 가능하다. 값이 수정되더라도 같은 Line을 가르키기 때문에 Entity로 보는것이 맞을 것 같다.
Section은 VO다. id를 제외한 모든 값이 같다면 같은 Section으로 보는 것이 일반적인 것 같다. Section은 수정할 수도 없기 때문에 VO로 보는것이 맞을 것 같다.
Reference
https://www.culttt.com/2014/04/30/difference-entities-value-objects/
