[도분설] 도메인 모델링

안녕하세요 강정호입니다. 오늘은 도메인 분석 설계에서 Domain Model의 역할에 대해서 알아보겠습니다.

도메인 모델링을 하는 이유

---

Domain Model : 컨셉의 시각화(Visualizing Concept)

1. 도메인 모델은 소프트웨어 구성요소(Software Component)가 아니다

- 개념적 클래스(즉 도메인)은 아이디어와 객체로 구성.

- 현실 세계의 객체를 시각화 한 것이다.

- 다음 구성요소들은 도메인 모델의 구성요소로서 적합하지 않다.

1) 윈도우, 데이터베이스와 같은 소프트웨어

2) 메서드

- 도메인 모델과 디자인 모델의 표현상의 갭을 줄이기 위한 목적으로 사용

1) Lower representational gap(LRG) : Use case 모델만으로는 바로 설계하기가 어렵다. 왜냐하면 Use case는 각 케이스간 관계 파악이 어렵기 때문이다. 그래서 도메인 설계를 먼저하고 설계 모델을 만든다.

- 도메인 기반의 디자인은 모델과 구현을 연결한다.

ㅁ

2. 도메인 모델과 분석

- 구조적 분석(Structured analysis)

1) 기능 중심으로 분석

2) 위에서 아래로 분석한다

- 객체 지향적 분석(Object oriented analysis)

1) 객체 중심으로 분석

2) 아래서 위로 분석한다

3. 도메인 모델은 어떻게 만드는가?

- 개념적 클래스가 될만한 것을 뽑아낸다(Find the conceptual classes)

- 클래스를 UML 클래스 다이어그램으로 그린다.

- 연관 관계와 속성을 추가한다.

** 개념적 클래스를 정의하는 3가지 원칙

1) 존재하는 모델을 재사용하거나 변경한다.

2) 명사형으로 정의한다.

- 명사와 명사 표현은 개념적 클래스 혹은 속성이 될 후보들이다.

3) 개념적 클래스 카테고리 리스트를 사용한다.

도메인 모델링 가이드라인(1 of 3)

1. 지도제작자(map maker)처럼 생각하라!

- Use existing names in the territory : 외부 사람들이 이해할 수 있도록 단어를 선택하라

- Exclude irrelavant or out-of-scope features : 범위에서 벗어나거나 관계 없는 특징은 배제하라

- Do not add thing that are not there : 존재하지 않는 것들은 추가하지 마라.

2. 실제 세계를 모델하라!

- Use the core vocabulary and concepts that domain experts use : 도메인 전문가들이 사용하는 핵심 단어, 개념들을 사용하라.

3. 속성(Attribute)와 클래스(Class)에 관한 잘못된 오해!

- 우리가 생각하기에 X라는 개념적 클래스를 텍스트나 숫자로 생각하지 않는다면 그것은 개념적 클래스이지 속성이 아니다. 즉 속성은 숫자, 텍스트로 나타낼 수 있는 것이다.

- 예시 : 가게와 매출은 분리되어야 하는 개념적 클래스들인가? 아니면 매출 아래에 가게라는 속성이 있어야 하는가?

** Store는 Text, 숫자로 표현할 수가 없는 개념이다. 그래서 개념적 클래스에 해당된다. Store 하위에 있는 phoneNo 전화번호는 숫자로 표현이 가능한 컬럼이기 때문에 Attribute에 해당한다.

가게 자체가 Attribute가 되기 어렵다. 즉 클래스가 되어야 하고 가게 번호, 가게 주소 등이 가게의 Attribute가 될 수 있다.

3. Specification 혹은 Description 개념적 클래스를 추가하라 언제? 다음과 같을 때

- 아이템이나 서비스에 대해 서술, 묘사가 필요할 때 독립적인 것으로 분리하기.

- 정보가 중복될 경우 분리하라.

- 매출, 생산품, 서비스, 제조 등에 공통적으로 존재할 경우

위와 같이 Item에 대해서 Description이 계속 중복된다면 아예 Description 도메인으로 분리해서 연관관계를 맺어주면 된다.

Description 클래스 예제

상황 : 항공사에서 비행기 일정을 취소하려고 한다. 비행기 객체는 항공일정이 취소되면 삭제된다.

Flight객체를 삭제하면 Flight의 객체과 그것과 연관관계를 맺고 있는 정보들이 모두 사라진다.

그래서 Flight Description 도메인을 독립적으로 분리하여 Flight 객체가 삭제되어도 유지될 수 있게 한다.