research

Domain Model 작성 가이드

Domain Model 작성 가이드

04-domain-model의 내용을 실제로 작성할 때 참고하는 가이드.

템플릿

# Domain Model: [프로젝트/Use Case 이름]

## 개념 클래스 후보

[Use Case 텍스트에서 명사를 뽑아 나열한다]

| 후보 | 채택 여부 | 이유 |
|---|---|---|
| ??? | O/X | ??? |

## Domain Model

(Mermaid classDiagram — 메서드 없음, 속성과 연관관계만)

## 결정 기록

[왜 이 클래스를 넣었는지, 왜 뺐는지 판단 근거]

작성 순서

Step 1: 명사 뽑기

Use Case 텍스트를 읽으면서 명사와 명사구를 전부 뽑는다. 판단하지 말고 일단 다 모은다.

예를 들어 수강 추천 UC에서:

"학생이 수강 과목 추천을 요청한다. 시스템이 학생의 이수 내역을 확인한다. 시스템이 학생의 로드맵을 확인한다. 시스템이 다음 학기 개설 과목과 졸업 요건을 비교한다. 시스템이 추천 과목 목록과 선택 이유를 제시한다..."

뽑히는 명사들: 학생, 이수 내역, 로드맵, 개설 과목, 졸업 요건, 추천 과목 목록, 시간표, ...

Step 2: 카테고리 체크리스트로 보강

명사 뽑기만으로는 놓치는 게 있다. 아래 카테고리를 훑으며 추가 후보를 찾는다.

| 카테고리 | 질문 | 예시 | |---|---|---| | 트랜잭션 | 기록해야 할 사건이 있나? | 추천 요청, 수강 신청 | | 트랜잭션 라인아이템 | 트랜잭션 안의 개별 항목? | 추천된 개별 과목 | | 명세/설명 | 뭔가를 설명하는 정보? | 과목 정보, 졸업 요건 | | 역할 | 사람의 역할? | 학생 | | 장소 | 관련 장소? | 학과, 대학 | | 컨테이너 | 뭔가를 담는 것? | 교과과정, 시간표 | | 외부 시스템 | 연동 대상? | 학교 포털, LLM | | 카탈로그 | 목록/모음? | 개설 과목 목록 |

Step 3: 후보 걸러내기

모든 명사가 개념 클래스가 되는 건 아니다. 걸러내는 기준:

빼야 하는 것:

  • 시스템 자체 (우리가 만드는 것)
  • 단순 속성인 것 (이름, 날짜, 점수 같은 단순 값 → 다른 클래스의 속성으로 들어감)
  • 구현 용어 (DB, API, 컨트롤러 등)

판단이 애매할 때:

  • "이게 속성인가 별도 클래스인가?" → 자체적인 속성이 2개 이상이면 별도 클래스. 예: "과목명"은 속성이지만, "과목(이름, 학점, 시간, 교수)"은 클래스.
  • "이거 넣어야 하나?" → 넣는 게 낫다. 나중에 빼기는 쉽지만 빠진 걸 발견하기는 어렵다.

Step 4: 속성 추가

각 개념 클래스에 단순 데이터 타입 속성만 넣는다.

허용되는 속성 타입: 숫자, 문자열, 날짜, Boolean, 열거형

O  Sale { dateTime, isComplete }
X  Sale { payment: Payment }     ← 이건 연관관계로 표현

판단 기준: "이 값이 단순한 텍스트/숫자인가?" → 속성. "이 값이 자체적인 구조를 가진 개념인가?" → 별도 클래스 + 연관관계.

Step 5: 연관관계 추가

두 클래스 사이에 기억해야 할 관계가 있으면 연관관계를 그린다.

고우선순위 연관관계 체크리스트:

| 패턴 | 예시 | |---|---| | A는 B를 포함한다 | 시간표는 시간대별 과목을 포함한다 | | A는 B에 기록된다 | 추천 결과는 추천 기록에 기록된다 | | A는 B의 설명이다 | 과목 정보는 개설 과목의 설명이다 | | A는 B의 라인아이템이다 | 추천 과목은 추천 목록의 라인아이템이다 | | A는 B를 사용한다 | 학생은 로드맵을 사용한다 | | A는 B의 멤버다 | 학생은 학과의 멤버다 |

Step 6: 다중성(Multiplicity) 표기

연관관계 양 끝에 몇 개씩 연결되는지 표기한다.

| 표기 | 의미 | |---|---| | 1 | 정확히 1개 | | * | 0개 이상 | | 1..* | 1개 이상 | | 0..1 | 0개 또는 1개 |

예: 학생 "1" -- "0..1" 로드맵 → 학생 한 명에 로드맵은 없거나 하나.

Mermaid로 그리는 법

메서드는 안 넣는다. Domain Model은 현실 세계 개념이지 소프트웨어가 아니다.

연관관계 화살표 종류:

| 문법 | 의미 | 언제 쓰나 | |---|---|---| | A -- B | 양방향 연관 | Domain Model에서 기본으로 사용 | | A --o B | 집약 (빈 다이아몬드) | "B가 A를 포함" 관계일 때 |

Domain Model에서는 대부분 -- (양방향)만 써도 충분하다. 방향성(navigability)은 DCD에서 결정한다.

흔한 실수

  • 메서드를 넣는다 → Domain Model에는 메서드가 없다. 메서드는 09-design-class-diagram|DCD에서.
  • 구현 클래스를 넣는다 → Database, Controller, Repository 같은 건 소프트웨어 클래스. Domain Model에 안 들어감.
  • 속성에 다른 클래스를 넣는다 → Student { roadmap: Roadmap }은 틀림. 연관관계 선으로 표현.
  • 너무 적게 넣는다 → 애매하면 일단 넣어라. 빼기는 쉽다.
  • 너무 세밀하게 한다 → Iteration 1에서 완벽한 Domain Model은 필요 없다. 현재 Use Case에 필요한 만큼만.
← research 목록으로홈으로