도메인은 여러 하위 도메인으로 구성된다.
카탈로그 하위 도메인은 고객에게 구매할 수 있는 상품 목록을 제공하고, 주문 하위 도메인은 고객의 주문을 처리한다.
혜택 하위 도메인은 쿠폰이나 특별 할인과 같은 서비스를 제공하고, 배송 하위 도메인은 고객에게 구매한 상품을 전달하는 일련의 과정을 처리한다.
소프트웨어가 도메인의 모든 기능을 제공하지 않는다.
- 하위 도메인을 어떻게 구성할지 여부는 상황에 따라 달라진다. 기업 고객을 대상으로 대형 장비를 판매하는 곳은 온라인으로 카탈로그를 제공하고 주문서를 받는 정도만 필요할 것이다.
( 반면에 의류나 액세서리처럼 일반 고객을 대상으로 물건을 판매한다면 카탈로그, 리뷰, 주문, 결제, 배송, 회원 기능이 필요할 것이다. )
개념 모델과 구현 모델.
개념 모델은 순수하게 문제를 분석한 결과물이다. 개념 모델은 데이터베이스, 트랜잭션 처리, 성능, 구현 기술과 같은 것들을 고려하고 있지 않기 때문에 실제 코드를 작성할 때 개념 모델을 있는 그대로 사용할 수 없다. 그래서 개념 모델을 구현 가능한 형태의 모델로 전환하는 과정을 거치게 된다.
엔티티
: 엔티티의 가장 큰 특징은 식별자를 갖는다는 것이다. 식별자는 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다. 예를 들어, 주문 도메인에서 각 주문은 주문번호를 갖는데 이 주문번호는 각 주문마다 서로 다르다.
엔티티의 식별자 생성.
: 엔티티티의 식별자를 생성하는 시점은 도메인의 특징과 사용하는 기술에 따라 달라진다.
- 특정 규칙에 따라 생성
- UUID 사용
- 값을 직접 입력
- 일련번호 사용 (시퀀스나 DB의 자동 증가 칼럼 사용)
"UUID(universally unique identifier)"를 사용해서 식별자를 생성할 수 있다.
(다수의 개발 언어가 UUID 생성기를 제공하고 있으므로 마땅한 규칙이 없다면 UUID를 식별자로 사용해도 된다.)
UUID uuid = UUID.randomUUID();
String strUuid = uuid.toString(); 도메인 모델에 set 메서드 넣지 않기
: 도메인 모델에 get/set 메서드를 무조건 추가하는 것은 좋지 않는 버릇이다. 특히 set 메서드는 도메인의 핵심 개념이나 의도를 코드에서 사라지게 한다.
public class Order{
public void setShippingInfo(ShippingInfo newShipping){ }
public void setOrderState(OrderState state){ }
}-> changeShippingInfo()가 배송지 정보를 새로 변경하다는 의미를 가졌다면 setShippingInfo() 메서드는 단순히 배송지 값을 설정한다는 것을 뜻한다.
complete-Payment()는 결제를 완료했다는 의미를 갖는 반면에 setOrderState()는 단순히 주문 상태 값을 설정한다는 것을 뜻한다.
DTO의 get/set 메서드
: Data Transfer Object의 약자로 프레젠테이션 계층과 도메인 계층이 데이터를 서로 주고받을 때 사용하는 일종의 구조체이다. ```
코드를 입력하세요
최근의 개발 프레임워크나 개발 도구는 set 메서드가 아닌 private 필드에 직접 값을 할당할 수 있는 기능을 제공하고 있다. 따라서 set 메서드를 제공하지 않아도 프레임워크를 이용해서 데이터를 전달받을 수 있다.
