도메인 모델 시작하기

도메인이란?

 

- 도메인 : SW로 해결하고자 하는 문제 영역

- 도메인은 여러 하위 도메인으로 구성됨.

- 한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능 제공

 

- 특정 도메인 위한 SW라고 해서 도메인이 제공해야 할 모든 기능을 직접 구현하지 않음.

- 일부 기능은 자체 시스템으로 구현, 나머지 기능은 외부 시스템 사용

EX) 온라인 쇼핑몰은 외부 배송 업체의 시스템 사용. 필요한 기능만 일부 연동

도메인 전문가와 개발자 간 지식 공유

- 요구사항은 첫 단추와 같음. 코딩에 앞서 요구사항을 올바르게 이해하는 것이 중요.

- 개발자와 전문가가 직접 대화하는게 베스트

- 이해관계자와 개발자도 도메인 지식을 갖춰야

- 잘못된 값이 들어가면 잘못된 결과가 나옴. 요구사항도 마찬가지

- 관련자가 요구한 내용이 항상 올바른 것이 아님, 실제로 원하는 것을 정확히 표현 못할 때도 있음. 대화를 통해 찾아나가야

 

도메인 모델

- 도메인 모델 : 특정 도메인을 개념적으로 표현한 것

 

- 도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는데 도움됨.

- 도메인을 이해하려도메인이 제공하는 기능 및 주요 데이터 구성을 파악해야.

-> 기능과 데이터를 함께 보여주는 객체 모델은 도메인 모델링에 적합.

- 도메인을 이해하는데 도움이 된다면 표현 방식은 중요하지 않음. 구현 기술에 맞는 구현 모델이 필요.

- 도메인에 따라 용어 의미가 결정되므로 여러 하위 도메인을 하나의 다이어그램에 모델링 하면 안 됨.

- 각 하위 도메인마다 별도로 모델을 만들어야

 

도메인 모델 패턴

- 일반적인 애플리케이션 아키텍처는 다음과 같이 4개의 영역으로 구성

 

표현 : 사용자 인터페이스 

- 사용자 요청을 처리 및 정보를 보여줌.

- 사용자 뿐 아니라 외부 시스템일 수도 있음.

응용

- 사용자가 요청한 기능 실행

- 업무 로직 직접 구현 X

- 메인 계층을 조합해서 기능 실행

도메인

- 시스템이 제공할 도메인 규칙 구현

인프라스트럭처 

- DB나 메시징 시스템과 같은 외부 시스템과 연동 처리

 

도메인 계층은 도메인 핵심 규칙 구현

- 도메인 모델 패턴 : 도메인 규칙을 객체 지향 기법으로 구현하는 패턴

- 핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야 할 때 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있게 됨

- 개념 모델은 순수하게 문제를 분석한 결과물

- 실제 코드를 작성할 때 개념 모델을 있는 그대로 사용할 수 없음.

- 개념 모델을 구현 가능한 형태의 모델로 전환하는 과정을 거치게 됨.

- 개념 모델을 만들 때 처음부터 완벽하게 도메인을 표현하는 것은 사실상 불가능

- 도메인 지식이 시간을 지나면서 다른 의미로 해석 가능

- 처음부터 완벽한 개념 모델을 만들기 보다는 전반적인 개요 수준으로 개념 모델 작성

 

도메인 모델 추출

- 도메인 모델 기본 작업은 요구사항에서 모델의 핵심 구성요소, 규칙을 찾는 것.

- 요구사항에서 도메인이 어떤 기능을 하는지 메서드로 추출하고, 각 요구사항이 어떤 데이터로 구성되는지 분석

- 도메인을 구현하다 보면 특정 조건이나 상태에 따라 제약이나 규칙이 달리 적용되는 경우가 많음

 

ex)

메서드 예

- 한 상품을 한 개 이상 주문할 수 있음

- 각 상품 구매 가격 합은 상품 가격에 구매 개수를 곱한 값

 

 

문서화

- 문서화의 이유는 지식을 공유하기 위함.

- 코드를 보면서 도메인을 깊에 이해하게 되므로 코드 자체도 문서화의 대상

 

엔티티와 벨류

- 도출한 모델은 크게 엔티티와 밸류로 구분

- 엔티티 : 식별자를 가짐. 다른 상태가 바뀌더라도 식별자는 바뀌지 않음. 식별자가 같으면 엔티티도 같다고 판단

- 벨류 타입:  개념적으로 완전한 하나 표현. 의미를 명확하게 표현하기 위해 벨류 타입을 쓰는 경우도 있음

- 벨류 객체의 데이터 변경 시에는 기존 데이터 변경 보다는 변경 값을 가지는 새로운 벨류 객체 생성 방식을 선호 : 불변 객체

- 도메인에서 특별한 의미를 지니는 경우가 많기 때문에 식별자를 위한 벨류 타입을 사용해서 의미를 잘 드러내도록 할 수 있음

- 도메인 모델에 setter/getter 를 무조건 추가하는 것은 비추

- set메서드는 필드 값만 변경하고 끝나기 떄문에 상태 변경과 관련된 도메인 지식이 코드에서 사라짐.

- 또한 객체 생성 시 온전하지 않은 상태가 될 수 있음

- 도메인 객체가 불완전한 상태로 사용되는 것을 막으려면 생성 시점에 필요한 것을 전달해 주어야 한다.

- 생성자를 통해 필요한 데이터를 모두 받아야 한다.

 

도메인 용어와 유비쿼터스 언어

- 코드를 도메인 용어로 해석하거나 도메인 용어를 코드로 해석하는 과정이 줄어들어야.

도메인 용어 반영 안 된 예

도메인 용어 반영된 예

- 유비쿼터스 언어 : 전문가, 관계자, 개발자가 도메인과 관련된 공통 언어를 만들고, 대화, 문서 도메인 모델, 코드, 테스트 등 같은 용어를 사용하는 것. 소통 과정에서 용어의 모호함 줄이며, 도메인과 코드 사이에서 불필요한 해석 과정 줄일 수 있음.

 

- 리포지토리 : 도메인 객체를 DB에 저장할 때 사용하는 구성 요소

 

참조

도메인 주도 개발 시작하기 - 최범균 저