🏗 도메인 주도 설계(DDD) - 파트 2 모델 주도 설계의 빌딩 블록 w. 코드

🎯 도메인 모델과 코드의 관계

📌 DDD의 핵심 원칙:
"도메인 모델과 코드는 같은 의미를 가져야 한다."
즉, 코드 자체가 도메인 모델을 반영해야 하며, 별도로 문서를 유지보수할 필요가 없어야 함.

✅ 해결해야 할 두 가지 문제
1️⃣ 요구사항에 적합한 모습으로 도메인을 어떻게 모델링할 것인가?
2️⃣ 도메인을 반영한 코드를 어떻게 개발할 것인가?

💡 코드가 문서 역할을 한다면?
✔ 변경되는 문서를 따로 유지보수할 필요 없이,
✔ 코드를 보면 도메인 모델을 이해할 수 있도록 설계하는 것이 핵심.

---

🔨 모델 주도 설계의 빌딩 블록

빌딩 블록은 DDD를 코드로 구현할 때 복잡도를 낮추기 위한 가이드라인입니다.

📌 필수적인 개념은 아니지만, 직관적인 가이드 역할을 수행

✅ 도메인을 표현하는 빌딩 블록

• Association (연관 관계)
• Value Object (값 객체)
• Entity (엔터티)
• Service (서비스)
• Module (모듈)

✅ 생명주기를 관리하는 빌딩 블록

• Aggregate (애그리게이트)
• Repository (리포지토리)
• Factory (팩토리)

💡 결론: 도메인의 개념을 코드로 옮기기 위한 직관적인 가이드!
✔ 하지만 반드시 이 방식으로 구현해야 하는 것은 아님.

---

🔄 불변식 (Invariant)

📌 불변식이란?
정상적인 상태를 규정하는 비즈니스 규칙
즉, 도메인 모델이 항상 유지해야 하는 조건

✅ 예제: 음식 주문 시스템
1️⃣ 판매 중인 메뉴에는 옵션 그룹이 한 개 이상 존재해야 한다.

• ✅ 예: "고기 1인 세트"에는 삼겹살/목살 옵션이 있어야 함
  2️⃣ 판매 중인 메뉴의 옵션 가격은 0원 이상이어야 한다.
• ✅ 예: 삼겹살 옵션이 0원 이상이어야 함
  3️⃣ 판매 중인 메뉴에는 필수 옵션 그룹이 한 개 이상 존재해야 한다.
• ✅ 예: "고기 종류" 옵션은 반드시 선택해야 함

📌 불변식이 기획 단계에서 규정되기 어려운 이유
✔ 기획에서는 세부적인 조건을 모두 정의하지 못하는 경우가 많음
✔ 개발팀이 구현 단계에서 정확한 불변식을 도출하고 검증하는 역할을 수행해야 함

---

🔗 엔터티(Entity)와 값 객체(Value Object)의 차이

📌 엔터티(Entity): 식별성이 중요한 객체
✔ 동일한 객체가 계속 유지되어야 하는 경우
✔ 고유한 ID(식별자)를 기반으로 구분됨

✅ 예제
💰 "내가 빌려준 만 원짜리 지폐는 반드시 같은 지폐여야 한다!"
➡ 이 경우 "현금" 객체는 엔터티(Entity)

 

📌 JPA 엔터티(Entity)와 DDD 엔터티는 다른 개념
✔ DDD 엔터티: 도메인 행위 중심, 불변식 기반으로 설계
✔ JPA 엔터티: 테이블 매핑 중심, 데이터 저장을 위한 ORM 구조

💡 JPA를 사용할 때 주의할 점

• JPA는 관계형 데이터베이스를 기반으로 설계됨
• DDD의 개념과 충돌하는 경우가 있음
• 엔터티의 라이프사이클을 명확하게 정의해야 유지보수성이 높아짐

 

📌 값 객체(Value Object): 식별성이 필요 없는 객체
✔ 객체의 속성이 중요하고, 고유한 식별자는 필요 없음
✔ 값이 동일하면 같은 객체로 간주

✅ 예제
💳 "내가 빌려준 만 원짜리 지폐를 네이버 페이로 받아도 된다."
➡ 이 경우 "금액(Money)"은 값 객체(Value Object)

💡 엔터티보다 값 객체가 더 다루기 쉬움!
➡ 처음에는 값을 객체로 만들고, 필요할 때 엔터티로 변경하는 것이 좋음.

 

💡 DDD 관점에서 값 객체는 변경이 불가능(Immutable)해야 한다.

• 만약 값 객체의 값을 수정해야 한다면,
  기존 객체를 삭제하고 새로운 객체를 생성해야 함
• DB 관점에서는 trade-off가 있음
  • 값 객체를 삭제 후 다시 저장하면 불필요한 데이터 변경이 발생
  • 하지만, DDD에서는 비즈니스 모델을 유지하는 것이 더 중요

✅ 예제: 주문 항목(OrderItem)

• price를 수정할 때, 기존 OrderItem을 삭제하고 새로운 OrderItem을 생성해야 함
• DB에서는 이를 UPDATE 대신 DELETE + INSERT로 처리해야 하는 문제가 발생

---

🔄 연관 관계와 애그리게이트 (Aggregate)

📌 애그리게이트란?
✔ 엔터티와 값 객체를 논리적으로 묶어서 단순화하는 개념
✔ 데이터 변경의 단위를 결정하는 역할

📌 왜 애그리게이트가 필요할까?

• 도메인 모델이 복잡할수록, 연관 관계를 단순화해야 함
• 엔터티 간 직접적인 연관 관계를 맺으면 유지보수가 어려워짐

✅ 예제: 음식 주문 시스템
✔ "주문(Order) - 주문 항목(OrderLineItem)"
✔ 주문 항목은 주문 애그리게이트 내에서 관리됨
✔ 고객(Customer)과 주문(Order)은 별개의 애그리게이트로 분리

💡 애그리게이트를 정의하면 연관 관계를 최소화하여, 코드 복잡성을 줄일 수 있음.

---

🛠 코드 예제: 배달 도메인

🛒 주문(Order) 애그리게이트

class Order {
  private orderId: string;
  private customerId: string;
  private items: OrderItem[];
  private status: OrderStatus;

  constructor(orderId: string, customerId: string, items: OrderItem[]) {
    if (items.length === 0) {
      throw new Error("주문에는 최소 한 개 이상의 상품이 필요합니다.");
    }
    this.orderId = orderId;
    this.customerId = customerId;
    this.items = items;
    this.status = OrderStatus.PENDING;
  }

  completeOrder() {
    if (this.status !== OrderStatus.PENDING) {
      throw new Error("주문을 완료할 수 없는 상태입니다.");
    }
    this.status = OrderStatus.COMPLETED;
  }
}

---

🍔 주문 항목(OrderItem) - 값 객체

class OrderItem {
  private productId: string;
  private quantity: number;
  private price: number;

  constructor(productId: string, quantity: number, price: number) {
    if (quantity <= 0) {
      throw new Error("수량은 1개 이상이어야 합니다.");
    }
    if (price < 0) {
      throw new Error("가격은 0원 이상이어야 합니다.");
    }
    this.productId = productId;
    this.quantity = quantity;
    this.price = price;
  }

  getTotalPrice(): number {
    return this.quantity * this.price;
  }
}

 

📦 리포지토리 (Repository)

class OrderRepository {
  private orders: Map<string, Order> = new Map();

  save(order: Order) {
    this.orders.set(order.getOrderId(), order);
  }

  findById(orderId: string): Order | undefined {
    return this.orders.get(orderId);
  }
}

 

---

🔧 Factory 패턴 (객체 생성 로직을 분리)

📌 Factory 패턴이 필요한 이유
✔ 애그리게이트 생성이 복잡할 때, 이를 캡슐화하기 위해 사용
✔ 외부 DB 조회가 필요하거나 불변식이 복잡한 경우 Factory로 이관

✅ 예제: 장바구니 (Cart)

 

class CartFactory {
  static createCart(customerId: string, items: CartItem[]): Cart {
    if (items.length === 0) {
      throw new Error("장바구니에는 최소 한 개의 상품이 있어야 합니다.");
    }
    return new Cart(customerId, items);
  }
}

 

💡 Factory를 활용하면 도메인 객체의 생성을 한 곳에서 관리할 수 있음.

---

🎯 도메인 서비스 (Domain Service)

📌 도메인 서비스란?
✔ 특정 엔터티에 속하지 않는 비즈니스 로직을 처리하는 서비스
✔ 객체 간의 책임이 명확하지 않을 때, 별도의 서비스로 분리

✔ 꼭 필요한지 검토해 볼 필요 있음

✅ 예제: 할인 로직 (Discount Service)

 

class DiscountService {
  static applyDiscount(order: Order, discountRate: number): number {
    if (discountRate < 0 || discountRate > 1) {
      throw new Error("할인율은 0~1 사이의 값이어야 합니다.");
    }
    return order.getTotalPrice() * (1 - discountRate);
  }
}

 

💡 특정 애그리게이트에 포함하기 어려운 로직을 도메인 서비스로 분리할 수 있음.

---

🏆 결론: DDD의 빌딩 블록을 활용하면?

✅ 도메인 모델과 코드를 일치시켜 유지보수 부담을 줄일 수 있음
✅ 엔터티와 값 객체를 구분하여 식별성 문제를 해결할 수 있음
✅ 애그리게이트를 활용하여 연관 관계를 단순화하고 데이터 변경의 경계를 설정할 수 있음
✅ Factory를 활용하여 복잡한 객체 생성을 캡슐화할 수 있음
✅ 도메인 서비스로 특정 비즈니스 로직을 분리하여 관리할 수 있음

💡 DDD의 빌딩 블록은 복잡한 도메인을 쉽게 구현할 수 있도록 도와주는 강력한 가이드입니다! 🚀