답변.

도메인 주도 설계(DDD)는 소프트웨어 시스템 설계 접근법으로, 주제 영역과 그 논리에 집중합니다. DDD는 복잡한 도메인 영역을 연결되지만 독립적인 경계가 있는 컨텍스트(bounded contexts)로 나눕니다. 각 컨텍스트는 도메인 전문가와 합의한 특정 언어(Ubiquitous Language)를 개발합니다. DDD의 주요 구성 요소는 다음과 같습니다:

• Entity: 고유한 식별자와 생명 주기를 가진 객체(예: 주문).
• Value Object: 고유한 식별자가 없는 변경 불가능한 객체(예: 배송지 주소).
• Aggregate & Aggregate Root: 모든 변경이 집합 루트를 통해 이루어지는 객체의 모음.
• Repository: 집합과 상호작용하는 층.
• Service: 특정 객체와 관련이 없는 작업.

제한된 컨텍스트는 종종 명시적으로 설명된 API 또는 이벤트를 통해 상호 작용하는 개별 마이크로서비스로 구성됩니다.

Java(Spring) 코드 예시:

// Value Object 예시
@Embeddable
public class Address {
  private String city;
  private String street;
  // ... 생성자, equals, hashCode
}

// 집합 루트가 있는 Entity 예시
@Entity
public class Order {
  @Id
  private Long id;
  @Embedded
  private Address deliveryAddress;
  // ... 비즈니스 메소드
}

주요 특징:

• 주제 영역의 명확한 분할과 논리의 컨테이너화.
• 격리에 의한 개발 및 확장성 향상.
• 팀의 기술적 언어와 비즈니스 언어의 일관성 증가.

함정 질문.

DDD의 모든 객체는 Entity인가요?

아니요, Value Object도 존재하며, 이들은 고유성이 없고 상태가 정체성을 완전히 결정합니다.

Address a1 = new Address("모스크바", "아르bat");
Address a2 = new Address("모스크바", "아르bat");
System.out.println(a1.equals(a2)); // true

마이크로서비스로 나눈다는 것이 DDD를 적용하는 것인가요?

아니요, 단일 애플리케이션 내에서도 DDD를 적용할 수 있으며, 내부 컨텍스트 경계를 구축할 수 있습니다.

모든 집합에 대한 리포지토리가 항상 필요한가요?

보통 그렇지만, 경우에 따라 집합이 다른 집합의 일부로 완전히 저장될 수 있습니다. 이 경우 그것은 별도의 비즈니스 거래의 루트가 아닙니다.