도메인 주도 설계 - 5. 소프트웨어에서 표현되는 모델(ENTITY, VO, ...)

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

---

ENTITY(엔티티, 참조객체)

어떤 객체를 일차적으로 해당 객체의 식별성으로 정의되는 것으로 ENTITY의 생명주기 동안에 내용이나 속성이 바뀌어도 연속성이 유지되는 것을 말한다. ENTITY에 포함된 속성보다는 정체성(식별성)에 초점을 맞춘 객체이다.

 

예시 1: 경기장 좌석이 지정석인 경우 좌석은 ENTITY이다. 좌석의 식별자는 좌석 번호이고 경기장에서 유일하다.

예시 2: 경기장 좌석이 빈 좌석을 찾아 앉는 일반석인 경우 좌석은 ENTITY가 아니다. 전체 좌석의 개수가 중요하고 좌석번호가 물리적으로 새겨져 있더라도 소프트웨어에서는 그 번호를 관리할 필요는 없다.

ENTITY 모델링

ENTITY의 기본적인 책임은 연속성을 확립하는 것이다. ENTITY의 속성이나 행위에 집중하기보다 ENTITY 객체의 가장 본질적인 특징만 정의한다. 개념에 필수적인 행위만 추가하고 그 행위에 필요한 속성만 추가한다. 

식별 연산의 설계

각 ENTITY에는 다른 객체와 구분해줄 식별성을 만들어내는 수단이 반드시 있어야 한다. 식별에 사용되는 속성은 시스템내에서 유일해야 한다. 어떻게 두 객체가 개념적으로 동일한 ENTITY를 나타내는지 생각해봐야 한다. 이를 정의하려면 도메인을 이해해야 한다.

한 객체를 구분할 수 있는 실질적인 고유키가 없다면 각 객체에 ID를 부여한다.

 

VALUE OBJECT(값 객체)

개념적 식별성이 없는 객체를 VALUE OBJECT라고 한다. 

ENTITY의 식별성을 관리하는 일은 아주 중요하나 그 밖의 객체에 식별성을 추가하는 것은 시스템 성능을 저해하고 분석 작업이 별도로 필요해진다. 모든 객체를 동일한 것으로 보이게 해서 모델이 복잡해진다.

 VALUE OBJECT는 어느 것인지는 관심이 없고 무엇인지에 대해서만 관심이 있다. 색은 문자열이나 숫자와 마찬가지로 대표적인 VALUE OBJECT이다. 어떤 VALUE OBJECT는 다른 여러 객체를 조립한 것일 수 도 있다(레고 처럼).

 VALUE OBJECT는 ENTITY를 참조할 수도 있다. 데이트 코스가 있다면 각각의 장소가 있을 것이다. 데이트 코스는 장소들을 참조하는 세 객체가 ENTITY이더라도 데이트 코스 자체는 VALUE OBJECT이다. 

• 모델에 포함된 어떤 요소의 속성에만 관심이 있다면 그것을 VALUE OBJECT로 분류해야 한다.
• VALUE OBJET는 불변적으로 다뤄야 한다.
• VALUE OBJECT에 식별성을 부여하지 말고 ENTITY를 유지하는데 필요한 설계상의 복장성을 피해야 한다.

VALUE OBJECT의 설계

 두 사람이 동일한 이름 가지고 있다고 해서 동일 인물인 것은 아니다. 그래서 이름을 나타내는 객체는 서로 바꿀 수 있다. Name 객체는 두 Person 객체 간에 공유할 수 있다. 그러나, Name객체가 공유된다면 한사람의 이름이 바뀌면 다른 사람의 이름도 바뀔 것이다. 이러한 이유로 VALUE OBJECT는 불변적이어야 한다.

 

VALUE OBJECT는 많아지는 경향이 있어서 성능 최적화를 위한 대안을 마련해야 할 수도 있다. 각 전기 콘센트가 개별 VO라면 하나의 주택도면에도 수백개의 VO가 있을 지도 모른다. 그러나 콘센트를 단순이 한 콘센트 인스턴스를 공유해서 수백번에 걸쳐 같은것을 가리키게 할 수 도 있다(FLY WEIGHT 디자인 패턴).

변경가능성을 허용하는 경우

• VALUE가 자주 변경되는 경우
• 객체 생성/ 삭제에 비용이 많이 드는 경우
• VALUE를 공유할 일이 많지 않은 경우

VALUE의 구현이 변경 가능하다면 공유해서는 안된다.

 

SERVICE(서비스)

 SERVICE는 모델에서 독립적인 인터페이스로 제공되는 연산으로써 도메인 객체(ENTITY나 VO)로는 어울리지 않고 도메인 연산이나 행위에 대한 책임을 가지고 있는 모델이다.

 필요한 도메인 기능을 ENTITY나 VO에 억지로 맡게 하면 모델에 기반을 둔 객체의 정의가 왜곡될 수 있다.

SEVICE는 독립적인 인터페이스로 제공되는 연산이다. 이름은 UBIQUITOUS LANGUAGE에서 유래하거나 UBIQUITOUS LANGUAGE에 도입돼야 한다. 매개변수와 결과는 도메인 객체여야 한다.

 

잘 만들어진 SERVICE의 특징

1. 연산이 원래부터 ENTITY나 VALUE OBJECT의 일부를 구성하지 않고 도메인 개념과 관련되어 있다.
2. 인터페이스가 도메인 모델의 외적 요소의 측면에서 정의된다.
3. 상태를 갖지 않는다.

MODULE(모듈) 

 모듈로 쪼개지는 것은 코드가 아닌 도메인 개념이다.

어떤 사람이 한 번에 생각해낼 수 있는 양은 한계가 있다(낮은 결합도 필요).

일관성이 없는 단편적인 생각은 이해하기 어렵다(높은 응집도 필요).

어떤 MODULE을 분석할 때 해당 MODULE의 내용물과 상호작용하는 것에 대해 조금만 알고 있어도 분석이 가능해진다.

MODULE 이름은 UBIQUITOUS LANGUAGE로 구성된다. MODULE과 그 이름은 도메인에 통찰력을 줄 수 있어야 한다.

MODULE과 그 안에 도메인 개념만으로도 그 자체를 이해할 수 있어야 한다.