DDD 05장 - 소프트웨어에서 표현되는 모델 (1)
본 포스트는 도메인 주도 설계 라는 책을 참조하였습니다. 가능하면 본 책을 직접 보시고 DDD를 이해하는 것을 추천드립니다. http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=12174216
- 모델과 구현은 상세 수준에서 연결돼야 한다.
- 객체 간 연관관계(association)를 설계하고, 합리적으로 구성
- 하지만 실제로 구현 하는 것은 생각보다 힘든 일이다.
Entity, Value Object, Service, Module
Entity : 연속성(continuity)과 식별성(identity)을 가지는 객체 - 유일성
Value Object : 단순 값(상태를 기술하는 속성에 불과)을 가지는 객체
Service : 행동(action)이나 연산(operation)으로 명확하게 표현되는 객체
- 상태를 주고 받지 않는 활동 을 모델링
- 하지만 결국에는 중요 행위는
Entity가 담당해야하며,Service는 위임에 가깝다.
Module : 모델의 한 부분. 고로 모델처럼 도메인의 개념을 반영
연관관계
모델 내의 모든 탐색 가능한(trabersable) 연관관계에 대해 그것과 동일한 특성을 지닌 메커니즘이 소프트웨어에도 있다. ?? 정확한 이해가 안됨
연관관계를 쉽게 다루는 세가지 방법
탐색 방향을 부여한다.
- 양방향 탐색에 비해 상호 의존성이 줄어들어 설계가 단순해 진다.
- 추가적으로 도메인의 본질적인 방향성이 드러날 수도 있다.
양방향 상태
- 미국의 대통령은 조지 워싱턴이다. 조지 워싱턴은 미국의 대통령이다.
단방향 정리
- 미국의 대통령은 누구입니까? : 적합한 방향성
- 조지 워싱턴이 대통령이었던 나라는 어디입니까? : 어색한 방향성
한정자(qualifier)를 추가해서 사실상 다중성(multiplicity)을 줄인다.
- 한정자를 통해서 1:N 과 같은 다중성이 1:1 관계로 줄일 수 있다. - 제약
미국(1)의 대통령은 여러 명(N)이다. 하지만 1790년(한정자)에 미국(1)의 대통령은 조지 워싱턴(1)이다.
중요하지 않은 연관관계를 제거한다.
- 양방향에서 단방향으로 한가지 연관관계 제거
- M:N > 1:N > 1:1 으로 연관관계 단순화
도메인의 특성을 찾아내서 연관관계를 일관되게 제약(한정자를 통해서)하면 의사전달력이 풍부해지고 구현이 단순해지며, 나머지 양방향 연관관계도 의미를 지니게 된다. 또한 문제가 되지 않거나 중요한 모델 객체가 아니라면 궁극적인 단순화는 연관관계를 완전히 제거하는 것이다.
Entity
객체는 속성이 아닌 연속성과 식별성이 이어지느냐를 기준으로 정의된다 - 유일성
속성은 객체를 상태일 뿐이다.
어떤 객체를 일차적으로 해당 객체의 식별성으로 정의할 경우 그 객체를 Entity라 한다. Entity는 자신의 생명주기 동안 형태와 내용이 급격하게 바뀔 수도 있지만 연속성은 유지해야 한다. 식별성을 기반으로 Entity를 추적(CRUD)한다.
Entity의 클래스 정의와 책임, 속성, 연관관계는 Entity에 포함된 특정 속성보다는 Entity의 정체성에 초점을 맞춰야한다. 의미에 따라 Entity를 분류한다면 모델이 더욱 투명해지고 구현은 견고해질 것이다.
예를 들면 사람, 도시, 자동차, 티켓, 은행거래와 같은 것이 Entity가 될 수 있다. 역으로 모델 내의 모든 객체가 Entity는 아니다.
Entity의 식별성과 언어상의 동일성(자바기준
==연산자)을 연결시키지 말자. 하지만 최근의 ORM 기술은 Entity의 식별성을 언어에서 제공하는 동일성으로 커버할 수 있게 되었다 !!!
Entity의 생명주기의 연속성과 식별성에 집중하고, 클래스의 정의를 단순하게 한다. 객체의 속성으로 동일성을 판단하는 것은 매우 위험하다. 객체의 유일한 결과를 반환하는 즉 유일성을 나타낼 수 있게 하는 연산을 정의하라.
위에서 제공하는 유일성 판단방법은 모델에서 식별셩을 구분하는 방법과 일치해야한다. 모델은 동일하다는 것이 무슨 의미인지 정의해야 한다.
ORM 기술을 이용하면 위 Entity와 관련된 기술적 요구사항을 대부분 만족시킬 수 있다.
- 생명주기와 연속성 :
EntityManager, 영속화 Context - 식별성 :
@Id,==,
예를 들면 경기장 좌석 예매 시스템에서 지정좌석(좌석번호)과 참석자(아이디)는 Entity로 다룰 수 있다. 지정좌석의 경우 예매 후 경기가 끝날 때까지 유지되어야 한다.
좌석번호가 없는 자유석의 경우에는 식별자가 존재하지 않으므로 Entity로 다룰 수 없다.
Entity 모델링
- 속성 ?
- 행위 ?
- 본질적인 특징
- (개념에) 필수적인 행위만
- 행위에 필요한 속성만
- 연관관계
- 다른 Entity나 Value Object
|  |
식별 연산의 설계
식별성 : 동일성 판단
식별성의 정의는 도메인의 이해에서
- 유니크 인덱스 ?
- 복합키 ?
- 자연키
- 대리키 : ID기호
중요한 것은 유일성
자연키를 예를 들면
- 주민등록번호
- 전화번호
대리키를 예를 들면
- 택배번호
- 예약번호
Value Object
개념적 식별성이 없는 객체도 많은데, 이런 객체는 사물의 어떤 특징을 표현한다. - 사물을 서술하는 객체
예를들면
- 쇼핑몰의 고객에게는 주소는
Value Object - 우체국 주소관리 체계에서 주소는
Entity
위의 예시 또한 도메인과 설계에 따라서 달라질 수 있다.
일반적인 값 객체도 Value Object
IntegerColorRoute: 경로Route의 경우 도시라는 Entity에 연관관계를 가지고 있지만 Value Object 이다
어떤 요소의 속성에만 관심이 있으면 ValueObject이다.
Value Object는 불변(immutable)객체여야 한다. 또한 식별성을 부여하지 않는다. 즉 단순하게 설계한다.
Value Object의 설계
모든 값이 같다(동등성)고 해서 같은 객체(동일성)일 필요는 없다. - 불변식
다이어그램으로 예를들면
모든 값이 같다고 해서 같은 Value Object를 참조해서는 안된다. Value Object 공유로 인해서 예상치 못한 속성 변화가 생길 수 있다.
모든 값이 같다고 다른 곳에서 참조하면 불변식이 위배되므로, (Entity 별로) 다른 Value Object(새로운 레퍼런스)를 참조해야 한다.
Value Object를 포함한 연관관계 설계
불변식은 필수다
Value Object 간 양방향 연관관계는 완전히 제거하도록 노력해야한다.
