도메인 주도 설계 - 05. 소프트웨어에서 표현되는 모델

도메인 모델을 표현하는 세 가지 패턴(entity, value object, service)에 대해 알아본다.

ENTITY

객체를 '식별성'에 의해 정의하는 경우, 이러한 객체를 entity라고 부른다. entity에는 모델링과 설계상의 특수한 고려사항이 포함돼 있다. entity는 생명주기동안
형태와 내용이 급격하게 바뀔 수도 있지만 핵심은 '연속성'을 유지하는 것이다. entity는 식별성을 가짐에 따라, 식별자에 의한 추적이 가능하다. entity에서 집중해야할 부분은
value object와는 달리 객체의 속성이 아니라 식별성에 의해 정의되는 정체성이다. entity의 식별자는 현실 세계에는 존재하지 않는 개념적인 식별자일 수도 있다.

VALUE OBJECT

entity의 식별성을 관리하는 일은 매우 중요하지만 그 밖의 객체에 식별성을 부여하는 것은 시스템의 성능을 저하시키고 별도의 분석 작업을 수반할 수 있다.
우리는 특별하게 다뤄야 할 부분과 그렇지 않은 부분을 구분해야 한다. 개념적인 식별성을 갖지 않으면서 도메인의 서술적 측면을 나타내는 객체를 Value object라고 한다.
우리는 시스템에서 VO를 바라볼 때 그것이 '어느 것'인지에는 관심이 없고 그것이 '무엇'인지에만 관심이 있다. 즉 해당 객체의 정체성보다는 객체의 속성에 집중한다.
VO는 '불변적'이며 '불연속적'이다.

value object를 활용한 데이터베이스 최적화

식별성이 부여될 필요가 없는 객체들을 적절히 VO로 정의한다면 denormalization을 이용한 데이터베이스 성능 최적화를 꾀할 수 있다. 한 VO 클래스에 대한 동일한 인스턴스가 여러개 있을 때
그 중 어느 것을 참조하는지는 중요하지 않다. DB 성능이 중요시될 때 객체 참조의 방식보다 VO의 사본을 저장하는 방법을 생각해볼 수 있다.

SERVICE

중요한 도메인 연산이지만, entity나 value object에 속하기엔 어색한 것들이 있다. 이것은 주로 사물이 아닌 활동이나 행동이다. 때때로 이렇게 도메인 영역에서
중요하게 다뤄지는 행위를 정의하기 위한 Service가 필요하다. Entity나 VO의 이름은 주로 명사로 부여되는 반면, Service의 이름은 주로 동사(행위)로 부여되는 경향이 강하다.
service가 책임지는 연산의 이름은 ubiquitous language에 포함되어 있어야 한다.

Service는 아래와 같은 세 가지 특징을 가진다.

• service가 책임지는 연산은 단순히 entity나 value object의 일부가 아니라, 애초부터 도메인 개념과 관련되어 있다.
• 인터페이스가 도메인 모델의 외적 요소의 측면에서 정의된다.
• 연산이 상태를 갖지 않는다.

service와 격리된 도메인 계층

entity 혹은 value object와는 달리, service는 도메인 계층에서만 이용되는 것이 아니다. service는 상황과 맥락에 따라 application layer 혹은 infrastructure layer에도
존재할 수 있다. 각 계층에서 활용되는 service의 예시는 다음과 같다.

응용	도메인	인프라
자금 이체 응용 서비스	자금 이체 도메인 서비스	통지 서비스

자금 이체 응용 서비스

• 입력 내용의 암호화
• 이체 처리를 위한 도메인 서비스로의 메세지 전송
• 이체 확인 대기
• 인프라스트럭처 서비스를 이용한 통지 결정

자금 이체 도메인 서비스

• 금액 인출/입금에 필요한 Account(계좌)와 Ledger(원장) 객체 간의 상호작용
• 이체 결과 확인 정보 제공

통지 서비스

• 애플리케이션에서 지정한 곳으로 이메일이나 우편 등을 보냄

응용 서비스와 도메인 서비스 모두 사물이 아닌 특정한 행위를 정의하는 서비스 객체이지만, 응용 서비스는 도메인 지식과는 아무 관련이 없다는 것에 주목해야 한다.

MODULE (모듈, 혹은 패키지)

모듈의 경우 위에서 설명한 내용보다 다소 그 개념이 와닿지 않았는데, 우선은 프로젝트에서 사용하는 디렉토리의 구조 정도로 이해했다.

인프라스트럭처 주도 패키지화의 함정

때때로 많은 프로젝트는 인프라가 스캐폴딩 기능을 통하여 제공하는 패키지 구조를 따르곤 한다.(우리 회사의 경우도 그러하고, 내 개인적으로 프로젝트를 진행할 때도 인프라스트럭처에 의해 주도되는 패키지 구조를 따랐다.) 도메인 주도 설계에 따르면 모듈의 구조는 도메인 지식을 반영하고 있어야 하며, 인프라스트럭처 주도 패키지화를 피해야 한다. 이는 클린 아키텍처를 공부하면서 학습했던 내용과도 일맥상통하고, 얼마 전 읽었던 문서에서도 이와 같은 맥락의 내용을 언급하고 있다. 다음 프로젝트에서는 도메인 지식을 담고 있는 모듈 구조를 도입해봐야겠다.