Domain Model (Ch 10-12)

도메인 모델은 문제 도메인의 현실 세계 개념을 시각화한 것이다. 소프트웨어 클래스가 아니다. 메서드가 없다. "이 세계에 어떤 것들이 존재하고, 서로 어떻게 연결되어 있는가"를 보여준다.

왜 만드는가

객체지향 분석의 핵심 행위는 도메인을 개념 클래스로 분해하는 것이다. 이 분해가 나중에 소프트웨어 설계의 출발점이 된다. 도메인 모델의 개념 클래스 이름이 소프트웨어 클래스 이름에 영감을 주고, 연관관계가 객체 간 메시지 흐름의 후보가 된다. 이것을 Larman은 "representational gap을 줄인다"고 표현한다 — 현실 세계와 소프트웨어 사이의 거리를 좁히는 것.

개념 클래스 식별법

1. 카테고리 리스트 기법 — 도메인에 흔히 존재하는 개념 유형을 체크리스트로 훑는다:

| 카테고리 | 예시 | | ----------- | -------------------------- | | 물리적/유형 객체 | Register, Item | | 명세/설명 | ProductSpecification | | 장소 | Store | | 트랜잭션 | Sale, Payment | | 트랜잭션 라인 아이템 | SalesLineItem | | 사람의 역할 | Cashier, Customer | | 컨테이너 | Store, ProductCatalog | | 외부 시스템 | CreditAuthorizationService | | 카탈로그 | ProductCatalog |

2. 명사구 식별 기법 — 유스케이스 텍스트에서 명사와 명사구를 뽑아 후보로 삼는다. 기계적으로 1:1 매핑은 안 되지만, 출발점으로 유용하다.

연관관계 (Ch 11)

연관관계는 "이 두 개념 사이에 기억해야 할 관계가 있는가"로 판단한다. 소프트웨어 구현이 아니라 순수하게 개념적인 진술이다.

고우선순위 연관관계 패턴:

A는 B의 물리적/논리적 부분이다 (SalesLineItem — Sale)
A는 B에 물리적/논리적으로 포함된다 (Register — Store)
A는 B에 기록된다 (Sale — Register)
A는 B의 설명이다 (ProductSpecification — Item)
A는 B의 라인 아이템이다 (SalesLineItem — Sale)

속성 (Ch 12)

속성은 단순 데이터 타입만 허용한다: 숫자, 문자열, 날짜, Boolean. 다른 개념 클래스를 속성으로 넣으면 안 된다 — 그건 연관관계로 표현해야 한다.

❌ Sale 클래스에 currentRegister: Register 속성 → 이건 외래키 사고방식 ✅ Sale과 Register 사이에 연관관계 화살표

Mermaid 예시: NextGen POS Domain Model

바이브 코딩에서의 활용

도메인 모델은 LLM에게 데이터 모델의 뼈대를 전달하는 가장 좋은 형태다. 엔티티, 관계, 속성이 한눈에 보이기 때문이다.

프롬프트 예시:
"다음 도메인 모델을 기반으로 데이터베이스 스키마와 엔티티 클래스를 만들어줘.

엔티티: Store, Register, Sale, SalesLineItem, ProductSpecification, Payment
관계:
- Store 1:N Register
- Register 1:N Sale (현재 진행 중인 Sale은 1개)
- Sale 1:N SalesLineItem
- Sale 1:1 Payment
- SalesLineItem N:1 ProductSpecification
- Store 1:1 ProductCatalog, ProductCatalog 1:N ProductSpecification

속성:
- Sale: dateTime, isComplete
- SalesLineItem: quantity
- ProductSpecification: description, price, itemID
- Payment: amount"

주의: 도메인 모델은 소프트웨어 설계가 아니니, LLM에게 전달할 때는 "이건 개념 모델이고, 실제 구현에서는 테이블 정규화나 추가 필드가 필요할 수 있다"고 알려주는 게 좋다.