DDD - Entity 인가 아닌가?

이것은 Entity 인가? 행위인가?

일반적으로 유저, Customer, Product 와 같은 것들이 Entity 로 모델링하는 것은 쉬울 수 있다.

하지만, 어떨때는 이것을 Entity로 모델링 해야하는 것인지 아닌지 헷갈리는 경우가 있다.

아래 포스팅에서 Entity 에 대한 개념에 대해서 알아보았다.

이번에는, 이 개념을 기반으로 예시를 들어 Entity 를 식별해보도록 해보자.

https://pius712.tistory.com/40

도메인 주도 설계 - entity

 

식별할 수 있는 사건

예시1. 결제

“결제” 라는 사건에 대해서 생각해보자.

결제를 단순화해보자면, 결제는 구매자 계좌에서 판매자 계좌로 가는 돈의 흐름이라고 볼 수 있다.

구매자와 판매자라는 두 Entity 간의 상태변화로 이해할 수 있다.

그렇다면, 이 “결제” 라는 것은 단순히 행위일까?

예시2. 게시글의 좋아요

“좋아요” 버튼을 누르는 행위에 대해서 생각해보자.

좋아요라는 것을 어떤 유저가 게시글의 좋아요 숫자를 증가시키는 행위로 이해할 수 있다.

그렇다면 이것은 그냥 행위에 불과할까?

서로 대체 불가능한 것

예시3. 이력관리

우리가 헬스장 주인이라고 생각해보자.

매일 사람들이 헬스장에 출석하는 것은 그저 행위일까?

어제 A 라는 사람이 출석한 것과 오늘 출석한 것은 같은 것일까?

돌고돌아 결국은 도메인 탐구

현실세계에서 일어나는 식별가능하고, 서로 구분되는 어떤 사건은 Entity 로 모델링할 수도 있다.

하지만, 꼭 그런 것은 아니다.

이에 대한 더 자세한 답은 도메인을 탐구하면서 얻을 수 있다.

우리가 만드는 도메인에서, 이러한 식별가능하고, 서로 구분되는 사건을

“식별해야하고, 추적가능해야한다면” Entity로 모델링해야한다.

식별할 수 있는 사건 예시 돌아보기

• 예시 1. 결제

결제는 일반적으로 도메인에서 중요한 사건(행위)으로 다뤄질 것이다. 따라서 Entity로 모델링한다.

• 예시 2. 좋아요

좋아요의 경우, 커뮤니티와 같은 도메인에서 중요한 사건으로 다뤄진다. 따라서 Entity로 모델링 된다.

사건에 대한 반례 살펴보기

단순히 특정 유저가 자신의 프로필을 바꾸는 사건은 어떠한가?

이것은 일반적으로 식별될 필요가 없으며, 추적될 필요도 없을 것이므로, Entity 로 모델링하지 않아도 될 것이다.

하지만, 이와 비슷하지만 건물의 표기사항을 변경하는 것은 어떠한가?

공공기관에서 건물에 관한 변경사항은 중요한 사건으로 다루어지기 때문에, Entity로 모델링될 것이다.

서로 대체 불가능한 것 예시 돌아보기

헬스장에서 출입 이력을 관리하는 것은 약간 애매한 면이 있다.

단순히 건물의 출입내역을 기록하는 용도라면, Entity로 모델링 될 필요가 없다.

하지만, 출입 이력을 기반으로 요금을 달리받는다거나, 이를 식별하여 무엇인가를 도출해야만 한다면 Entity로 모델링될 것이다.

단적인 예로, 화물의 배송 이력은 화물 도메인에서는 Entity 가 될 것이다.

결국 중요한 것은 우리 도메인에서 이것이 얼마나 중요하게 다뤄지며, 식별되어야하고, 추적되어야 하는가 를 살펴봐야한다.

로그는 Entity 인가?

그렇다면, 어떤 Entity 의 상태 변경을 로그 데이터로 쌓는 것도 엔티티일까?

이것도 이력이니까 Entity가 아닐까?

일반적으로 Entity 라고 볼 수 없을 것이다. Entity 의 상태 변경을 로그로 남기는 것이 우리 도메인의 기능적 요구사항인가? 아니면 비기능적 요구사항인가?

Entity 의 상태 변경을 추적하는 것은 도메인에서 일어나는 중요한 사건이 아니라 업무에 부가적인 도움을 주기위한 비기능적 요구사항이지, 도메인에서 중요한 역할을 하는 것이 아니다.