도메인 모델 시작하기

도메인이란 무엇일까?

그냥 아무 생각 없이 보면 내가 개발하는 영역을 음 그냥 데이터 베이스 테이블을 하나로 묶어서 기능을 나타낸다?  정도의 느낌이였다.
이를 더 구체적으로 보면 우리가 현실에서 마주치는 다양한 문제를 소프트웨어로 개발하여 해결할 수 있는데, 이 문제에 대한 영역을 도메인이라 한다.
예를들어 우리가 옷을 편리하게 구매하고 싶다면 핸드폰으로 주문할 수 있을 것이다.
옷을 편리하게 주문하는 것이 하나의 도메인일 것이다.
이 하나의 도메인은 여러 하위의 도메인으로 나뉘게 된다.
예를 들어 옷을 편리하게 주문하는 도메인은 
주문 도메인, 상품 도메인, 회원 도메인, 결제 도메인, 배송 도메인들 다양한 하위 도메인의 유기적인 조합으로 이루어진다.
이런 하위 도메인은 직접 개발할 수도 있지만 다양한 외부 API 를 이용해서 개발한다.
개발자는 도메인 전문가가 아니기 때문에 도메인 전문과의 충분한 대화를 통해 의도를 파악하고 그 의도에 맞게 개발하는게 중요하다
Garbage In Garbage Out이라는 말이 있듯이 개발하기 전 의도 파악이 중요하다.

 

도메인 모델

도메인 모델에는 다양한 정의가 존재한다.
기본적으로 도메인 모델은 특정 도메인을 개념적으로 표현한 것이다.
도메인 모델은 도메인에 대한 이해를 높이고 의도를 파악하는데 좋다.
예를들어  UML를 통해  도메인의 작업을 나타낼 수 있고
객체로 표현해 좀 더 프로그래밍과 가깝게끔 하여 개발자들에 이해를 도울 수 있다. 
즉 결국 도메인 모델은 도메인 자체를 이해하기 위한 개념이다. 
하위 도메인 모델들을 하나의 도메인 모델에 넣으려고하면 안된다.
하위 도메인은 같은 아이템을 갖고 있더라도 도메인마다 의미하는게 다를 수 있기 떄문이다.
예를들어 카탈로그 도메인에서 상품은 상품의 정보 즉 가격 수량 재고 등에대한 정보를 담고 있지만
배송 도메인에서의 상품은 물리적인 상품이기 때문이다.
즉 하위 도메인마다 별도의 도메인 모델을 만드는 것이 좋다.

 

도메인 모델 패턴 

일반적인 애플리케이션은 표현, 응용, 도메인, 인프라스트럭쳐 영역으로 구성된다.
표현은 사용자의 요청을 처리하고 그에 대한 응답을 보여준다. (프론트)
응용은 사용자가 요청한 기능을 실행한다. (API 실행)
도메인은 시세틈이 제공할 도메인 규칙을 구현한다. (도메인 객체 (객체의 정보와 기능을 명세한다.))
도메인의 핵심을 구현한 도메인 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 확장되어야할 때 다른 영역에 영향을 덜미친다. (객체지향 캡슐화)
인프라스트럭처는 데이터베이스나 메시징 시스템 등 외부 시스템과의 연동을 처리한다. (인프라)

 

개념모델과 구현모델

개발자는 도메인에 대한 개발을 할 수록 도메인에 대한 이해가 증가해 기존에 만든 모델을 보완하거나 변경하는 일이 잦다.
따라서 처음부터 너무 완벽한 개념 도메인 모델을 만들려하지 말고 도메인에 대한 개요와 이해를 위한 모델을 만들어야한다.

 

도메인 모델 도출

도메인을 모델링할 때 기본이 되는 작업은 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾고 정리하는 것이다.

이러한 과정은 문제 상황과 그에 따른 요구사항에서 출발한다. 

요구사항에 따라 엔티티의 필드와 메서드를 구현할 수 있습니다. 

즉 요구사항은 데이터, 메소드, 로직, 관계, 제약사항 등 들을 설정할 수 있게 합니다.

이러한 것들을 바로 코드로 작성하는 것 보다 더 상위 개념으로 정리를 하면 즉 문서화를 하면  
나중에 다른 개발자가 보거나 도메인 전문가가 확인하거나 개발하다 개념이 헷갈리 때 등 아주 도움이 될 것이다.

 

엔티티와 벨류 

도메인에서 도출한 모델은 크게 엔티티와 밸류로 구분할 수 있다.

엔티티의 가장 큰 특징은 식별자로 엔티티 객체마다 고유한 객체로 인식할 수 있게된다.

식별자 생성은 다양한 방식으로 구현할 수 있다.

특정규칙, UUID, NANOID, enumratedValue 등 

단 식별자는 unique한 값으로 절대로 겹치면 안되며 겹칠 수 없어야 한다.

 

벨류는 개념적으로 완전한 하나를 표현할 때 사용한다. 예를들어 관리자가 있다면 Manager라는 벨류 타입을 만들 수 있을 것이고 주소, 돈, 신체정보 등 ID가 필요없고 하나를 표현하며 엔티티의 값으로 들어가는 것을 벨류타입이라 할 수 있다. 

벨류타입을 불변객체로 박으면 안정성에 도움이 된다. 즉 불변객체의 내부 필드값을 변경하기 위해선 새로운 불변객체를 생성해서 넣어줘야 하는 것이다. 

도메인 모델은 setter를 넣는 것을 지양하고 set과 같은 역할을 하더라도 좀 더 구체적인 이름을 지어주는 것이 좋다.

즉 함수들의 이름을 보고 기능을 유추하며 도메인에 대한 이해를 돕도록 해야한다.

또는 setter를 private function으로 만들어서 생성자에서 사용하게 끔 할 수도 있다. 

 

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

코드를 작성할 때 개발자만 겨우 알아볼 수 있는 예를들어 STEP1 STEP2 STEP3 같은 직관성이 떨어지는 코드는 작성하면 안된다. 대신에 도메인에서 사용하는 언어 즉 개발자 도메인 전문가, 기획자가 공통으로 사용하는 언어 즉 유비쿼터스 언어를 사용해서 개발해야한다. 예를들어 처음에본 STEP1, STEP2, STEP3를 ORDER, SHIPPING, DELIVERY_COMPLETE로 나눌 수 있겠다