1.5 도메인 주도 설계 패턴명 및 용어집: 용어 해석 길라잡이 #1535
Description
1.5 도메인 주도 설계 패턴명 및 용어집: 용어 해석 길라잡이
1.5.1 단어의 의미를 생각하기
단어의 의미는 모호해서 사람에 따라 받아들이는 방식이 다릅니다.
에반스는 이것이 개발을 진행하는 데 있어 큰 문제이며, 이를 개선해야 좋은 설계로 이어질 수 있다고 생각하였습니다.
도메인 주도 설계의 많은 패턴은 단어 해석의 차이를 발견하고 인식을 맞추어 나가기 위한 사고와 설계 방식입니다.
나와 상대방의 인식 차이를 넘어서
독자의 머릿속 이미지와 필자의 머릿속 이미지는 일치하지 않습니다.
서로가 가지고 있는 경험과 지식이 다르기 때문입니다.
글을 쓰는 사람의 의도와 읽는 사람의 목적도 다릅니다.
그 실마리를 찾을 수 있는 것이 바로 도메인 주도 설계의 패턴입니다.
1.5.2 도메인 모델과 관련된 패턴과 용어
도메인 모델
도메인
도메인 주도 설계에서는 도메인을 비즈니스 활동의 영역 또는 업무의 영역이라는 의미로 사용합니다.
그리고 그 영역(도메인)에는 비즈니스 방침이나 업무 규칙과 같은 무언가 정해진 것이 있다는 것을 암시합니다.
도메인이 다르면 적용되는 규칙도 달라집니다. 기업마다 각각 자체적인 정책과 규칙에 따라 운영됩니다.
모델
모델(model)은 단순화입니다.
<도메인 주도 설계>에서는 ‘선택된 도메인의 특징을 기술하고 그 도메인과 관련된 문제를 해결하는 데 사용할 수 있는 추상 체계’라고 설명하고 있습니다.
즉, 모델은 선택과 추상화를 통해 전체를 간결하게 표현한 것입니다.
지식이 풍부한 설계와 깊이 있는 모델
지식이 풍부한 설계
지식이 풍부한 설계는 단편적인 지식의 양을 늘리는 것에서 한 걸음 더 나아가 중요한 업무 규칙을 파악하고, 업무 규칙 간의 중요한 관계를 파악하기 위해 도메인 모델을 만드는 것을 의미합니다.
지식의 풍부함은 지식의 양이 아니라 요점과 관계성에 대한 이해입니다.
깊이 있는 모델
깊이 있는 모델은 초기 단계에서 간과했던 중요한 업무 규칙을 발견하거나, 업무 규칙의 배경에 있는 암묵적인 프레임워크를 명시적으로 표현할 수 있는 도메인 모델입니다.
이러한 깊이 있는 이해에 도달하기 위해 업무를 지속적으로 학습하고 모델과 설계를 개선(리팩터링)하는 과정을 반복하는 것이 도메인 주도 설계의 방식입니다.
유비쿼터스 언어
실제 업무를 담당하는 사람들이 사용하는 언어를 개발자들도 사용하고, 그 언어가 클래스 이름이나 패키지 이름, 커밋 로그(commit log)에도 나타나는 것, 그것이 유비쿼터스 언어입니다.
언제 어디서든 모든 이해관계자가 같은 언어를 사용해서 개발하는 방식입니다.
선별된 기본 용어를 잘 정립하고 있으면, 그 주변으로 연결되는 다양한 용어에 대해서도 일관된 의미로 정리할 수 있다는 점이 도메인 모델과 유비쿼터스 언어의 관계입니다.
모델 주도 설계
도메인 모델을 바탕으로 클래스나 패키지를 설계할 수 있으며, 이런 접근 방식을 모델 주도 설계(MDD, Model-Driven Design)라고 합니다.
도메인 모델을 구성하는 요소
- 엔터티
- 값 객체
- 애그리게이트
- 도메인 이벤트
- 도메인 서비스
도메인 모델의 구성 요소라는 것은 이 패턴들이 클래스의 설계 패턴일 뿐만 아니라 업무 지식의 습득과 정리를 위한 패턴이며, 개발 진행 시 의도를 전달하기 위한 기본 용어를 정의하기 위한 패턴을 의미합니다.
이러한 패턴의 목적은 도메인 모델을 만들고 성장시켜 나가는 것입니다.
도메인 모델은 선별된 중요한 업무 지식입니다.
따라서 모든 클래스를 이 패턴에 맞춰 설계할 필요는 없습니다.
1.5.3 전략적 설계와 관련된 패턴과 용어
- 경계 컨텍스트
- 컨텍스트 맵
- 핵심 도메인
- 진화하는 질서
경계 컨텍스트
유비쿼터스 언어의 기반이 되는 도메인 모델도 필연적으로 경계 컨텍스트 안에서 만들어야만 모순 없이 일관성 있는 도메인 모델을 유지할 수 있습니다.
소프트웨어 개발에서 언어 해석의 차이에 크게 영향을 미치는 조건은 다음 세 가지입니다.
- 팀
- 소스 코드를 관리하는 단위
- 데이터베이스를 관리하는 단위
이 조건에 의해 구체적으로 결정되는 경계 컨텍스트와 모순되지 않는 일관된 도메인 모델과 유비쿼터스 언어가 통용되는 범위를 일치시키는 것이 전략적 설계의 기초가 됩니다.
컨텍스트 맵
여러 개의 경계 컨텍스트가 모여 대규모 시스템을 구성합니다.
그 전체 그림을 조망하는 모델이 바로 컨텍스트 맵입니다.
컨텍스트 맵은 시스템 전체에 대한 이해관계자들의 공통된 이해를 형성하는 데 유용하며, 크게 다음 두 가지 용도로 사용할 수 있습니다.
- 시스템 전체가 어떤 컨텍스트로 나뉘어져 있는지에 대한 인식 일치
- 컨텍스트 간의 연동 지점과 연동 방법에 대한 인식 일치
핵심 도메인
핵심 도메인 패턴은 중점적으로 투자해야 할 영역을 파악하기 위한 개념과 설계 방식입니다.
핵심 도메인은 타사와 차별화하여 비즈니스를 유지시키고 발전시키는 원동력이 되는 영역입니다.
일반적으로 핵심 도메인은 다음과 같은 세 가지 특성을 가집니다.
- 자사만의 고유한 업무 방식을 가지고 있다.
- 업무 프로세스, 업무 규칙이 복잡하다.
- 변화가 지속적으로 발생한다.
진화하는 질서
변화를 항상 컨텍스트 맵에 반영하면서 이해관계자들과 공통된 이해와 합의를 반복해야 합니다.
이때 전체 질서를 유지하면서 발전시키는 것이 중요한데, 이를 위한 패턴으로 책임 계층이 있습니다.
책임 계층은 하나의 도메인 모델 안에서 패키지의 역할을 구분하고 패키지 간의 의존 관계를 정리하기 위한 패턴입니다.
1.5.4 도메인 모델을 사용하는 패턴과 용어
도메인 모델의 핵심 부분을 움직이기 위한 패턴으로 다음과 같은 것이 있습니다.
- 애플리케이션 서비스(유스케이스)
- 팩토리
- 리포지터리
애플리케이션 서비스(유스케이스)
애그리게이트로 계산과 판단을 수행하는 클래스를 애플리케이션 서비스 또는 유스케이스라고 합니다.
애플리케이션 서비스는 이후에 설명하는 팩토리 패턴이나 리포지터리 패턴을 사용해 필요한 애그리게이트를 얻고, 그 애그리게이트를 사용해 계산과 판단을 실행하며, 필요에 따라서 계산과 판단의 결과를 리포지터리에 저장(지속화)합니다.
팩토리
팩토리는 복잡한 애그리게이트를 생성하는 책임을 애그리게이트로부터 분리하기 위한 패턴입니다.
애그리게이트가 본래의 역할에 집중할 수 있도록 애그리게이트를 생성하는 로직을 따로 분리하는 것입니다.
리포지터리
리포지터리는 애그리게이트의 계산과 판단 결과를 저장하고 이후 다시 사용할 수 있도록 분리하기 위한 패턴입니다.
애플리케이션 서비스의 관점에서 보면 리포지터리는 도메인 객체 컬렉션을 다루는 구조와 유사해 보일 수 있습니다.