DDD 세레나데 4주차 강의 정리

작성일 | In
NextStep DDD 세레나데 강의 정리

DDD 세레나데 4주차

3주차 복습

  • 전술적 설계 - ddd lite , building block
    • 특정 디자인 패턴이 필요하다면 building block에 포함되는 것이다.
  • 좋은 객체는 불변한 객체
    • 도메인 주도 설계 빌딩 블록중 불변인 것들을 vo 라고 부른다.
    • vo는 equals와 hashcode를 재정의 하는것을 권장한다.
    • 생성자 보다는 정적 팩토리 메소드를 사용해라.
  • Entity
    • 내부에 상태값이 변하는 객체들은 entity로 만들 수 있다.
    • entity는 식별자를 갖는다.
    • 도메인 모델에 set 메서드 넣지 않기

Aggregate

  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.

  • 공통적으로 사용하는 애그리거트는 baseAggregate과 같이 trade-off할 수 있다.

  • 수많은 aggregate중 root 로 만드는 방법은 외부에서 바라보는지를 확인 하면 된다.
  • 애그리거트 루트는 일관성이 깨지지 않도록 해야한다.
    • 생성자로 엔티티를 만들때 모든 속성을 가지고 있어야 한다.

  • 클라이언트는 애그리거트의 내부 구현이 어떻게 되어 있는지 몰라야 한다.

  • Aggregate 참조
    • subentity를 외부에 노출시키면 안된다.

    • Root entity를 기준으로 repository를 제공해줘야 한다.

    • 두개의 aggregate가 필요하다면 domain service가 도출되어야 한다.
    • 하나의 aggregate에서도 domain service가 발생할 수 있다.
  • Factory
    • 데이터를 가지고 있는 객체가 일을 하도록 메시지를 던져야 한다.

4주차

  • 계층형 아키텍처
    • 표현영역
      • httprequest, response, session을 관리
    • 응용 서비스
      • 로직을 직접 수행하기 보다는 도메인 모델에 로직 수행을 위임.
      • 도메인 영역에서 발생시킨 이벤트를 처리.
    • 도메인 서비스
      • 로직에 대한 버전 관리를 해야할 필요가 있는 경우 도메인 서비스가 될 수 있다.
      • 두개 이상의 aggregate를 사용하면 반드시 도메인 서비스가 되어야 한다.
        • 같은 aggregate라도 두개 이상을 사용한다면 도메인 서비스.
    • 메서드 파라미터와 값 리턴
      • 응용 서비스에 데이터로 전달할 파라미터가 두개 이상이면 데이터전달을 위한 별도 클래스를 사용하는것이 편리.
      • 응용 서비스는 표현 영역에서 필요한 데이터만 리턴하는 것이 기능 실행 로직의 응집도를 높이는 확실한 방법.
    • 값 검증
      • 값 검증은 표현영역과 응용 서비스 두 곳에서 모두 수행 할 수 있다.
      • 표현 영역에서 필수 값과 값의 형식을 검사하면 실질적으로 응용 서비스는 아이디 중복 여부와 같은 논리적 오류만 검사하면 된다.
    • 인터페이스는 어느 시점에 생성하는것이 적절한가
      • 외부와 연동할 가능성이 크거나 연동하고 있는 것은 인터페이스를 만드는 것이 좋다.
  • DTO
    • DTO는 프로세스 간에 데이터를 전달하는 객체가 아니고 구조체 라고 보는것이 맞다.
    • value object는 dto가 아니다.
    • value object는 어플리케이션 내부의 요구사항으로 만들어지고 dto는 어플리케이션 외부의 요구사항을 반영한다.
    • dto에서 entity를 만드는것은 괜찮으나 entity 에서 dto를 만드는것은 불가하다.
    • domain model everywhere
    • pure domain model
      • 항상 dto를 만드는 것은 실용적이지 않다.
        • -> vo로 해결 가능한 것은 vo로 해결 해도 된다.
        • vo는 영역과 관계없이 사용가능하기 때문이다.
  • 의존 역전 원칙
    • 고수준 모듈의 의존 문제
      • 저수준 모듈의 변경에 따라 고수준 모듈의 변경이 불가피 해진다.
    • DIP 주의 사항
      • 추상화 한 인터페이스는 저수준 모듈이 아닌 고수준 모듈에 위치 해야 한다.
      • 실제 구현은 infrastructure에서 구현(저수준)
    • 육각형, 양파, 클린 아키텍처
      • 공통된 목적은 내부에 있는 domain layerr를 외부로 부터 숨기고 지키는것이다.
      • 내부는 외부를 모르고 외부는 내부를 몰라야 한다.
  • anti corruption layer
    • 외부로부터 내부 도메인 레이어를 지키기 위한 계층
  • 주 생성자 -> 모든 상태를 가지고 있는 생성자
  • 부 생성자 -> 부생성자가 주 생성자를 호출하는 방법
  • 최상단 패키지는 Bounded Context로 나누고 Aggregate은 domain package에서 나누는 방
  • menu product가 price를 가지도록
  • infra - product 와 관련된 클래스를 만들고 productservice를 주입 받아 price를 얻는다 ? -> anti corruption layer 만든다