• 에릭 에반스의 서적 ‘Domain Driven Design’에서 에릭 에반스는 사용자가 마주할 가능성이 있는 다양한 종류의 도메인 개체에 대한 분류를 만듭니다.
  • Entity: 참조 객체라고 불리기도 하는 시간을 초월하는 뚜렷한 식별성과 다양한 표현식을 갖는 객체
  • Value Object: 애트리뷰트들의 조합이 중요한 객체입니다. 모든 속성에 대해서 동일한 값을 갖는 두 객체는 동일하다고 간주됩니다. Patterns of Enterprise Application Architecture(P of EAA)에서고 설명했었습니다.
  • Service: 도메인 컨텍스트 내에서 독립적으로 실행되는 작업을 의미합니다. Service Objcet(서비스 오브젝트)는 하나 이상의 서비스를 객체 안으로 모아놓습니다. 일반적으로 실행 컨텍스트 안에는 각각 서비스 오브젝트 타입의 인스턴스가 하나만 존재합니다.
• 이러한 분류는 도메인 모델에서 제가 필요하는 것들에 대한 저자의 경험과 잘 일치합니다. 문제는 이 3개를 정확하게 정의하기 어렵다는 것이죠. 이것들은 I know them when I see them(난 걔네를 보면 안다?)의 카테고리에 들어있거든요
• 이런 예시가 아마 도움이 될거에요. 엔티티들은 일반적으로 Customer, Shop, Rental Agreement 처럼 거대한 존재들입니다. Value는 일반적으로 Date, Money, Database Query와 같은 작은 존재들입니다. Service는 일반적으로 데이터베이스 커넥션, 메시징 게이트웨이, 레포지토리, 프로덕트 팩토리처럼 외부 자원 접속 포인트를 말합니다.
• 엔티티와 VO의 한가지 확실한 구별점은 VO는 hash같은 equality method(동등성 비교 메서드)를 오버라이드하지만 엔티티는 그렇지 않습니다. 이것은 일반적인 프로세스 컨텍스트 안에서 동일한 개념적 엔티티를 나타내는 객체가 둘 이상인 것을 원치 않기 때문입니다. 반면 “5.0” 객체는 몇개이든 상관 없습니다. VO는 아마 기본형 타입일 것이고 특정 언어에서는 지원하기도 합니다. 가장 중요한 규칙은 VO는 반드시 불변 객체여야 한다는 것입니다. 그렇지 않으면 aliasing bug와 같은 문제들이 발생합니다. 예를 들어 키와 같은 값을 바꾸고 싶다면 객체를 변경하지 말고 새로운 VO 객체로 변경하면 됩니다.
• 서비스 오브젝트는 종종 전역 변수, 클래스 필드 혹은 싱글톤을 사용해서 구현됩니다. 확실히 서비스 오브젝트 중 하나만 가지고 있다는 점에서 하나가 맞지만 어떻게 하면 더 다양하기도 합니다. 보통 특이점은 프로세스 컨텍스트 내에 있습니다. 멀티스레딩 환경 안에 스레드당 하나가 있는 것이죠. 어느 경우든 당신은 구현 메커니즘이 다른 도메인 오브젝트로부터 감춰져 있는 것을 보장해야 합니다 그래야 당신이 쉽게 그것들을 변경할 수 있습니다. 에릭은 그의 책 안에서 서비스는 반드시 무상태성을 지녀야한다고 주장했습니다.
• 이 영역에서 발생하는 문제 중 하나는 용어가 다른 아이디어들과 심하게 혼동되는 것입니다. 엔티티는 종종 데이터베이스 테이블이나 데이터베이스 테이블에 해당하는 객체를 표현할 때 사용됩니다. Service는 애플리케이션 아키텍쳐의 서비스 레이어 뿐만 아니라 Service 지향 아키텍쳐 에서도 사용됩니다. 따라서 만약 이런 용어를 사용하는 경우라면 에릭 에반스의 책에서 말하는 도메인 모델 컨텍스트에서 사용되는 의미임을 분명하게 밝혀야 합니다.