도메인 모델 시작하기

패턴이 중요한 것이 아니고 비즈니스 문제에 맞게 코드를 구성하는 것이 중요하다.

1.1 도메인

• 소프트웨어로 해결하고자 하는 문제 영역
• 여러 하위 도메인으로 구성된다.

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

• 각 영역에는 전문가가 있다.
  • 이들 전문가는 해당 도메인에 대한 지식과 경험을 바탕으로 본인들이 원하는 기능 개발을 요구한다.
• 개발자는 이러한 요구사항을 개발과 테스트과정을 거쳐 배포를 하게 된다.
  • 이 과정이 첫 단추와 같다.
  • 요구사항을 올바르게 이해해야 올바른 소프트웨어가 나온다.

그렇다면 요구사항을 올바르게 이해하려면 어떻게 해야 하나?

• 개발자와 전문가가 직접 대화하는 것이다.
• 다음으로 개발자도 도메인 지식을 갖춰야 한다.

알아두면 좋은 문장

• Garbage in, Garbage out
  • 잘못된 값이 들어가면 잘못된 결과가 나온다.
  • 잘못된 요구사항이 들어가면 잘못된 제품이 나온다.

1.3 도메인 모델

• 특정 도메인을 개념적으로 표현한 것이다.
• 도메인 모델을 기본적으로 도메인 자체를 이해하기 위한 개념 모델이다.
• 개념 모델을 이용해서 바로 코드를 작성할 수 잇는 것은 아니기에 구현 기술에 맞는 구현 모델이 따로 필요하다.
• 개념모델과 구현 모델은 서로 다른 것이지만 구현 모델이 개념 모델을 최디한 따르도록 할 수는 있다.

1.4 도메인 모델 패턴

• 일반적인 애플리케이션의 아키텍처는 아래와 같이 4개의 영역으로 구성된다.

 

 

영역 설명

사용자 인터페이스 또는 표현	사용자의 요청을 처리, 사용자에게 정보를 보여준다. 사용자는 소프트웨어를 사용하는 사용자일 수도 있고 외부 시스템일 수 도 있다.
응용	사용자가 요청한 기능을 실행한다. 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다.
도메인	시스템이 제공할 도메인 규칙을 구현한다.
인프라스트럭처	데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동을 처리한다.

 

개념 모델과 구현 모델

• 개념 모델은 순수하게 문제를 분석한 결과물이다.
  • 개념 모델은 데이터베이스, 트랜잭션 처리, 성능 , 구현 기술과 같은 것을 고려하고 있지 않기 때문에 실제 코드를 작성할 때 개념 모델을 있는 그대로 사용할 수 없다.
  • 개념모델을 구현 가능한 형태의 모델로 전환하는 과정을 거친다.
  • 도메인에 대한 전체 윤곽을 이해하는 데 집중하고, 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전시켜 나가야 한다.

 

1.5 도메인 모델 도출

• 도메인을 모델링할 때 기본이 되는 작업
  • 핵심 구성요소
  • 규칙
  • 기능

1.6 엔티티와 벨류

엔티티

• 서로 다른 식별자를 가진다.
  • 특정 규칙에 따라 생성
  • UUID나 Nano ID 와 같은 고유 식별자 생성기 사용
  • 값을 직접 입력
  • 일련번호 사용(시퀀스나 DB의 자동 증가 컬럼 사용)

벨류 타입

• 개념적으로 완전한 하나를 표현할 때 사용

엔니티 식별자와 벨류 타입

• 엔티티 식별자에 String과 같은 문자열로 구성된 경우가 많다.
• String 대신 EntityNo 밸류 타입을 사용하면 타입을 통해 해당 필드가 주문 번호라는 의미를 명확하게 드러낼 수 있다.

도메인 모델에 set 메서드 넣지 않기

• 습관처럼 set 메서드를 추가할 때가 있다.
• 하지만 이러한 메서드는 도메인의 핵심 개념이나 의도를 코드에서 사라지게 하는 문제점이 있다.

DTO 에는 set 메서드를 추가해도 될까?

• Data Transfer Object 약자
• 프레젠테이션 계층과 도메인 계층이 데이터를 서로 주고받을 때 사용하는 일종의 구조체이다.
• set 메서드를 사용해도 되지만 불변의 장점을 살리는 프레임워크를 사용해보자.