DCD에서 DB까지 — 빠진 연결고리

Larman은 요구사항에서 DCD까지, Fowler는 패턴 이름과 선택 기준을 준다. 하지만 DCD 클래스를 실제로 DB에 어떻게 연결하고, 이걸 어떤 다이어그램으로 표현하는지는 어디에도 명시적으로 정리되어 있지 않다. 이 노트가 그 gap을 채운다.

전체 흐름

Larman의 DCD (도메인 클래스)
    ↓
ER Diagram 설계 (DB 테이블 구조)
    ↓
매핑 패턴 선택 (Active Record / Data Mapper / Gateway)
    ↓
DCD 확장 (데이터 소스 클래스 추가)
    ↓
Sequence Diagram 확장 (Domain → DB 흐름)

Step 1: DCD에서 출발

Larman으로 만든 DCD에는 도메인 로직만 있고 DB 코드가 없다:

Step 2: ER Diagram — DB 쪽 설계

DCD를 보면서 관계형 DB에 어떻게 저장할지를 결정한다. 별도의 다이어그램이다:

여기서 첫 번째 판단: DCD 클래스와 DB 테이블이 거의 1:1인가? 그렇다면 05-data-source-patterns|Active Record가 유력. 아니라면 05-data-source-patterns|Data Mapper로.

Step 3: 패턴에 따른 DCD 확장

Active Record 방식

DCD 클래스 자체에 DB 접근 메서드를 추가한다. 도메인 로직과 DB 코드가 한 클래스에 공존:

장점은 단순함. 단점은 도메인과 DB가 강하게 결합됨.

Data Mapper 방식

별도의 Mapper 클래스를 만든다. 도메인 클래스는 DB의 존재를 모른다:

장점은 완전한 분리(도메인을 DB 없이 테스트 가능). 단점은 복잡성.

Step 4: Sequence Diagram 확장

Larman의 Interaction Diagram은 Controller → Domain까지만 그렸다. Fowler를 적용하면 Domain → Data Source → DB까지 이어진다.

Active Record 흐름

Data Mapper 흐름

핵심 차이: Active Record에서는 Student가 직접 DB와 대화하고, Data Mapper에서는 Student는 DB의 존재를 모르고 Mapper가 번역한다.

어떤 다이어그램을 언제 그리는가

| 무엇을 표현 | 다이어그램 종류 | 시점 | |---|---|---| | DB 테이블 구조 | ER Diagram | DCD 완성 후, 코딩 전 | | 데이터 소스 클래스 (Mapper, Gateway) | DCD 확장 (클래스 추가) | 매핑 패턴 선택 후 | | Controller → Domain → DB 전체 흐름 | Sequence Diagram 확장 | Interaction Diagram에 DB 계층 추가 | | DCD 클래스 ↔ DB 테이블 대응 | 매핑 테이블 (텍스트) | 설계 문서에 기록 |

"하나의 새로운 다이어그램"이 있는 게 아니라, Larman의 기존 다이어그램을 데이터 소스 계층까지 확장하는 것이다.

판단이 들어가는 지점들

이 과정에서 기계적으로 결정할 수 없는 것들:

어떤 매핑 패턴을 쓸지 — 도메인 복잡도와 클래스-테이블 일치도에 따른 판단
어디까지 Lazy Load할지 — 클라이언트가 데이터를 어떻게 쓰는지 알아야 결정 가능
상속을 어떻게 매핑할지 — Single Table / Class Table / Concrete Table 중 선택
Unit of Work가 필요한지 — 트랜잭션 범위와 동시성 요구사항에 따라 결정

이 판단들은 공식이 아니라 경험칙 + 프로젝트 맥락으로 내리는 것이다. Fowler가 제공한 건 "어떤 상황에서 어떤 패턴이 깨지는가"라는 경험의 프레임워크이지, 대입하면 답이 나오는 공식이 아니다.

실전에서 감각을 키우는 방법은 Iteration이다. 작은 범위에서 선택하고 → 구현하고 → 문제가 보이면 다음 Iteration에서 패턴을 바꾼다. 이것이 07-putting-it-all-together|Fowler가 CI/TDD/Refactoring을 강조하는 이유다.