: 소프트웨어로 해결하고자 하는 문제 영역(domain)
도메인은 여러 하위 도메인으로 구성된다.
예를 들어 온라인 서점 도메인에서,
카탈로그 하위 도메인 : 고객에게 구매할 수 있는 상품 목록 제공
주문 하위 도메인 : 고객의 주문 처리
한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공한다.
고객이 물건을 구매하면 주문, 결제, 혜택 하위 도메인의 기능이 엮이게 된다.
소프트웨어가 도메인의 모든 기능을 제공하진 않는다.
많은 온라인 쇼핑몰이 자체적으로 배송 시스템을 구축하기보다는 외부 배송 업체의 시스템을 사용한다.
결제 시스템의 경우에도 마찮가지이다. 직접 구현하는 경우보다 결제 대행업체를 이용해서 처리하는 경우가 많다.
도메인마다 고정된 하위 도메인이 존재하는 것은 아니다.
어떤 쇼핑몰은 고객에게 다양한 혜택을 제공하지만, 모든 쇼핑몰이 그러한 혜택을 제공하는 것은 아니다.
하위 도메인을 어떻게 구성할지 여부는 상황에 따라 달라진다.
Garbage in, Garbage out : 잘못된 요구사항이 들어가면 잘못된 제품이 나온다.
도메인 전문가의 요구를 개발자가 제대로 이해하는 것은 매우 중요하다.
예를 들어 회계 담당자는 정산 금액 계산을 자동화하는 기능을 개발자에게 요구할 수 있다. 이것을 제대로 이해하지 않고 개발이 이루어지면, 필요없거나 유용함이 떨어지는 시스템을 만들 수 있다. 또는 수정해야 할 코드가 많아져서 일정 등에 문제가 생기기도 한다.
요구사항을 제대로 이해하기 위한 방법
개발자와 전문가가 직접 대화하기 → 정보의 왜곡, 손실이 줄어든다.
개발자도 도메인 지식을 갖추어야 한다.
전문가나 관련자가 요구한 내용이 항상 올바른 것은 아니다. 실제 필요한 요구를 표현하지 못하는 경우도 있기 때문에 전문가와의 대화를 통해 진짜 요구사항을 찾아내야 한다.
: 특정 도메인을 개념적으로 표현한 것.
도메인 모델을 표현하는 방법은 다양하다.
→ 표현 방식은 중요하지 않고, 도메인을 이해할 수 있도록 하는 것이 중요하다.
도메인 모델은 도메인을 이해하기 위한 모델이기에 도메인 모델을 이용해서 바로 코드를 작성할 수 있는 것은 아니다.
→ 구현 기술에 맞는 구현 모델이 따로 필요하다.
어떤 도메인에 하위 도메인이 있을 경우, 하위 도메인에 대한 도메인 모델은 따로 만들어야 한다.
사용자 인터페이스(표현) : 사용자의 요청을 처리하고 사용자에게 정보를 보여 준다. 사용자는 소프트웨어를 사용하는 사람일 수도 있고, 외부 시스템일 수도 있다.
응용 : 사용자가 요청한 기능을 실행한다. 업무 로직을 집접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다.
도메인 : 시스템이 제공할 도메인 규칙을 구현한다.
주문 도메인의 ‘주문 취소는 배송 전에만 가능’과 같은 규칙을 구현한 코드는 도메인 계층에 위치하게 된다.
인프라스트럭처 : 데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동을 처리한다.
이러한 방식의 도메인 모델은 아키텍처 상의 도메인 계층을 객체 지향 기법으로 구현하는 패턴을 말한다.
핵심을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야 할 때 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있게 된다.