Chapter 1: 도메인 모델 시작하기

💡 책에서 기억하고 싶은 내용

시작하기

  • 소프트웨어가 도메인의 모든 기능을 제공하진 않는다

  • 요구사항을 올바르게 이해하기

    • 개발자와 전문가가 직접 대화하자!

도메인 모델

  • 도메인 자체를 이해하기 위한 개념 모델

    • 개념 모델을 이용해서 바로 코드를 작성할 수 있는 것은 아니므로, 구현 기술에 맞는 구현 모델이 따로 필요하다

  • 도메인은 다수의 하위 도메인으로 구성된다

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

    • 모델의 각 구성요소는 특정 도메인으로 한정할 때 비로소 의미가 완전해지기 때문에 각 하위 도메인마다 별도로 모델을 만들어야 한다

어플리케이션 아키텍처

  • 사용자 인터페이스 (UI) or 표현(Presentation)

    • 사용자의 요청을 처리하고 사용자에게 정보를 보여준다

      • 여기서 사용자는 소프트웨어를 사용하는 사람뿐만 아니라 외부 시스템 일 수도 있다

  • 응용 (Application)

    • 사용자가 요청한 기능을 실행한다

    • 업무 로직을 직접 구현하지 않으며, 도메인 계층을 조합해서 기능을 실행한다

  • 도메인

    • 시스템이 제공할 도메인 규칙을 구현한다

      • 도메인의 핵심 규칙을 구현!

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

  • Infrastructure

    • 데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동을 처리한다

개념 모델과 구현 모델

  • 개념 모델

    • 순수하게 문제를 분석한 결과물

    • 개념 모델은 데이터베이스, 트랜잭션 처리, 구현 기술과 같은 것을 고려하고 있지 않기 때문에 실제 코드를 작성할 때 개념 모델을 있는 그대로 사용할 수 없다

      • 그래서 개념 모델을 구현 가능한 형태의 모델로 전환하는 과정을 거치게 된다

    • 처음부터 완벽한 개념 모델을 만들기보다는, 전반적인 개요 를 알 수 있는 수준으로 개념 모델을 작성해야 한다.

      • 프로젝트 초기에는 개요 수준의 개념 모델로 도메인에 대한 전체 윤곽을 이해하는데 집중하고, 구현하는 과정에서 개념 모델을 구현 모델 로 점진적으로 발전시켜 나가야한다

도메인 모델 도출

  • 도메인을 모델링할 때 기본이 되는 작업

    • 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것

엔티티

  • 식별자 를 갖는다

    • 식별자는 엔티티 객체마다 고유해서, 각 엔티티는 서로 다른 식별자를 갖는다

  • 식별자는 바뀌지 않는다

    • 엔티티를 생성하고 속성을 바꾸고 삭제할 때까지 식별자는 유지된다

  • 식별자는 고유하고 바뀌지 않기 때문에, 두 엔티티의 식별자가 같으면 두 엔티티는 같다고 판단 할 수 있다

    • 식별자를 이용해서 equals() 와 hashCode() method를 구현할 수 있다

  • 엔티티의 식별자 생성

    • 특정 규칙에 따라 생성

      • 식별자를 먼저 만들고 엔티티 객체를 생성할 때 식별자를 전달

    • UUID나 Nano ID 같은 고유 식별자 생성기 사용

    • 값을 직접 입력

    • 일련번호 사용 (Sequence나 DB의 자동 증가 칼럼)

밸류 타입

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

    • ex) 배송 수신인 이름 + 주소 → Receiver class

  • 곡 두 개 이상의 데이터를 가져야 하는 것은 아님!

    • 의미를 명확하게 표현하기 위해 밸류 타입을 사용하는 경우도 있다

  • 밸류 객체의 데이터를 변경 할 때는, 기존 데이터를 변경하기보다는 변경한 데이터를 갖는 새로운 밸류 객체를 생성 하는 방식을 선호한다

    • 데이터 변경 기능을 제공하지 않는 타입을 불변 (Immutable) 이라고 표현한다

    • 밸류 타입을 불변으로 구현하는 이유 중 가장 중요한 이유는 안전한 코드 를 작성할 수 있다는 것이다

      • 불변 객체는 참조 투명성스레드에 안전 한 특징을 갖고 있다

  • 두 밸류 객체를 비교할 때는 모든 속성이 같은지 비교한다

엔티티 식별자와 밸류 타입

  • 식별자는 단순히 문자열이 아니라 도메인에서 특별한 의미를 지니는 경우가 많기 때문에, 식별자를 위한 밸류 타입 을 사용해서 의미가 잘 드러나도록 할 수 있다

    • ex) 주문번호로 String type 대신 OrderNo 밸류 타입 사용

도메인 모델에 set method 넣지 않기

  • set method는 도메인의 핵심 개념이나 의도를 코드에서 사라지게 한다

    • set method는 field 값만 변경하고 끝나기 때문에 상태 변경과 관련된 도메인 지식이 코드에서 사라지게 된다

  • set method 로 인해 도메인 객체를 생성할 때 온전하지 않은 상태가 될 수 있다

    • set method로 데이터를 전달하도록 구현하면, 처음 객체를 생성하는 시점에 완전하지 않게 된다

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

    • 즉, 생성자를 통해 필요한 데이터를 모두 받아야 한다

    • 생성자로 필요한 것을 모두 받기 때문에, 생성자를 호출하는 시점에 필요한 데이터가 올바른지 검사할 수 있다

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

  • 유비쿼터스 언어

    • 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어를 사용하는 것

    • 소통의 과정에서 발생하는 용어의 모호함을 줄일 수 있고, 개발자는 도메인과 코드 사이에서 불필요한 해석 과정을 줄 일 수 있다!

Last updated