도메인 모델링과 구현의 단위 — 어디서 쪼개는가

how-to-scope-requirements|요구사항에서 기능 그룹을 나눈 뒤, 도메인 모델링과 구현을 어떤 단위로 진행해야 하는가. 결론: 도메인 모델은 한 번에, 구현은 기능 그룹 단위로.

도메인 모델은 v1 전체를 한 번에 본다

기능 그룹이 이렇게 나뉘어 있을 때:

[수업 관리]          [시간표 시각화]        [알림]
 - 수업 등록          - 주간 뷰             - 수업 전 알림
 - 수업 수정          - 충돌 표시
 - 수업 삭제

도메인 모델을 [수업 관리]만 보고 설계하면 안 된다. 개념들은 기능 그룹을 넘나들기 때문이다:

Course와 Lecture라는 개념은 세 기능 그룹 모두가 공유한다. [수업 관리]만 보고 설계하면 color 필드를 빠뜨릴 수 있고 (시각화에 필요), [알림]만 보면 room 필드를 빠뜨릴 수 있다 (이동 시간 계산에 필요).

기능 그룹은 사용자 행동 기준, 도메인 모델은 현실 개념 기준이다. 이 둘의 경계가 다르기 때문에 도메인 모델은 전체를 한 눈에 보고 그려야 한다.

도메인 모델을 한 번에 그렸으면, 구현은 한 기능 그룹씩 진행한다. 두 가지 이유:

1) 피드백을 빨리 받을 수 있다. 세 그룹을 다 구현한 뒤 "이거 아닌데"보다, [수업 관리]만 만들고 실제로 써보면서 "이 모델이 맞나?" 확인하는 게 훨씬 싸다.

2) 기능 그룹 간에 의존 방향이 있다:

[수업 관리] → [시간표 시각화] → [알림]
 (데이터 생성)   (데이터 표시)    (데이터 기반 동작)

데이터를 만드는 쪽을 먼저 구현하는 게 자연스럽다.

등록/수정/삭제는 같은 개념(Course)에 대한 다른 조작이다. "수업 등록"만 놓고 도메인을 설계하면 시야가 너무 좁아진다:

따로 설계하면 세 번 만든 Course가 미묘하게 달라질 수 있다. 기능 그룹 단위로 "Course에 대해 할 수 있는 모든 것"을 한번에 보는 게 맞다.

1. 도메인 모델: v1 전체 개념 관계를 한 장에 그린다 (30분~1시간)
2. [수업 관리] 구현 → 실제로 써본다 → 모델 수정 필요하면 수정
3. [시간표 시각화] 구현 → 써본다 → 모델 수정
4. [알림] 구현 → 써본다 → 모델 수정

도메인 모델을 처음에 완벽하게 그릴 필요는 없다. "대략 맞는 전체 그림"을 먼저 그리고, 기능 그룹을 하나씩 구현하면서 수정해나간다. how-to-design-a-program-from-scratch|설계 프로세스의 피드백 루프가 여기서 작동한다.