도메인 주도 개발 (DDD, Domain-Driven Design)

---

(A) 특징

도메인 주도 개발(DDD)은 본질적인 비즈니스 모델을 중심으로 프로젝트를 설계하는 방법론이다. 이는 단순한 기술적인 접근이 아니라, 개발을 조직적으로 효율화하기 위한 전략이다.

(B) 주요 요인

1. 도메인 (Domain)

도메인은 특정 비즈니스 영역을 의미하며, 해당 프로젝트에서 다루는 핵심 개념을 정의한다.

• 예: 금융 시스템에서는 "거래", "거래자", "거래 결과" 등이 주요 도메인 요소이다.

2. 도메인 모델 (Domain Model)

도메인 모델은 도메인을 현실적으로 반영한 개념적인 구조이다.

• 예: "거래 만들기" 테스트를 통해 거래 생성 프로세스를 검증할 수 있다.

3. 유비쿼터스 언어 (Ubiquitous Language)

도메인 전문가, 프로그래머, 개발자 등이 공통적으로 이해하는 언어를 의미한다.

• 예: "애그리게이트"는 관련된 개체들의 집합을 의미한다.

4. 경계된 컨텍스트 (Bounded Context)

도메인의 범위를 명확하게 설정하여, 복잡성을 줄이고 독립적인 개발을 가능하게 한다.

• 예: "거래"와 "회계"를 분리하여 각 기능이 서로 간섭하지 않도록 한다.

(C) 도메인 주도 개발의 구성 요소

1. 엔티티 (Entity)

고유한 식별자를 가지는 개체로, 비즈니스에서 중요한 요소이다.

• 예: Order, User

2. 값 객체 (Value Object)

불변성을 가지며, 동일성을 기준으로 비교되는 객체이다.

• 예: Money, Address

3. 애그리게이트 (Aggregate)

관련된 엔티티와 값 객체들을 하나로 묶은 단위이다.

• 예: 거래는 "거래 상품"과 "회계 처리"의 결과를 포함할 수 있다.

4. 도메인 서비스 (Domain Service)

단일 개체로 표현하기 어려운 도메인 로직을 별도의 서비스로 분리한다.

• 예: "거래와 회계를 일치시키는 서비스"

5. 리포지토리 (Repository)

도메인 객체를 영속화하기 위한 저장소이다.

• 예: UserRepository, OrderRepository

(D) 장점

• 복잡한 도메인을 명확하게 표현할 수 있다.
• 독립적인 서비스로 구성하여 복잡성을 낮출 수 있다.
• 도메인 경험이 확장될 때, 기존 기능과 충돌을 최소화할 수 있다.

1. 공유 커널 (Shared Kernel)

---

(A) 개요

Bounded Context 간 공통된 개념을 공유하는 방식으로, 일관된 데이터 모델을 유지하는 데 유용하다.

(B) 프로젝트 구성

1. 공유 커널 모듈

@Entity
public class User {
    @Id
    private Long id;
    private String name;
    private String email;
}

2. 주문 서비스 (Order 도메인)

@Service
public class OrderService {
    private final UserRepository userRepository;

    public OrderService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public void createOrder(Long userId) {
        User user = userRepository.findById(userId).orElseThrow();
        System.out.println("Order created for user: " + user.getName());
    }
}

3. 결제 서비스 (Payment 도메인)

@Service
public class PaymentService {
    private final UserRepository userRepository;

    public PaymentService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public void processPayment(Long userId) {
        User user = userRepository.findById(userId).orElseThrow();
        System.out.println("Processing payment for user: " + user.getEmail());
    }
}

(C) 평가

• 장점: 데이터 일관성을 유지할 수 있다.
• 단점: 공유 커널이 변경되면 모든 도메인에 영향을 미칠 수 있다.
• 대안: 버전 관리와 독립적인 변경 전략을 적용해야 한다.

2. 동기 호출 (Synchronous Call)

---

(A) 설명

동기 호출 방식은 A 도메인에서 B 도메인의 서비스를 직접 호출하는 구조이다.

• 예: OrderService (A) → PaymentService (B)

(B) 프로젝트 구성

1. 호출자 (A 도메인)

@Service
public class OrderService {
    private final PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    public void placeOrder(Order order) {
        boolean isPaid = paymentService.isPaymentCompleted(order.getId());
        if (isPaid) {
            order.confirm();
        } else {
            throw new RuntimeException("Payment is not completed!");
        }
    }
}

2. 호출 대상 (B 도메인)

@Service
public class PaymentService {
    public boolean isPaymentCompleted(Long orderId) {
        return true;
    }
}

(C) 평가

• 장점: 성능이 빠르고 구현이 간단하다.
• 단점: 도메인 간 강한 결합이 발생할 수 있다.
• 대안: 비동기 방식 또는 이벤트 기반 구조를 고려할 수 있다.

3. API 호출 (REST, gRPC)

---

(A) 설명

API 호출 방식에서는 A 도메인에서 B 도메인의 API를 호출하여 데이터를 가져오거나 처리 요청을 보낸다.

• 예: OrderService (A) → PaymentService (B)

(B) 프로젝트 구성

1. REST API 호출 (A 도메인)

@Service
public class OrderService {
    private final RestTemplate restTemplate;

    public OrderService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public void placeOrder(Long orderId) {
        String url = "http://payment-service/payments/status/" + orderId;
        Boolean isPaid = restTemplate.getForObject(url, Boolean.class);

        if (Boolean.TRUE.equals(isPaid)) {
            System.out.println("Payment completed, order confirmed!");
        } else {
            throw new RuntimeException("Payment is not completed!");
        }
    }
}

2. API 제공 (B 도메인)

@RestController
@RequestMapping("/payments")
public class PaymentController {
    private final PaymentService paymentService;

    public PaymentController(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    @GetMapping("/status/{orderId}")
    public ResponseEntity<Boolean> checkPaymentStatus(@PathVariable Long orderId) {
        boolean isPaid = paymentService.isPaymentCompleted(orderId);
        return ResponseEntity.ok(isPaid);
    }
}

(C) 평가

• 장점: 서비스 간 독립성을 유지하면서도 필요한 데이터를 요청할 수 있다.
• 단점: API 서버의 부하가 커질 경우 성능 저하가 발생할 수 있다.
• 대안: API Gateway를 사용하거나, 캐싱 전략을 도입하여 성능을 개선할 수 있다.

4. 이벤트 기반 비동기 호출 (Kafka, RabbitMQ)

---

(A) 설명

이벤트 기반 방식에서는 A 도메인이 이벤트를 발행(Publish)하고, B 도메인은 이를 구독(Subscribe)하여 비동기적으로 연동된다.

(B) 프로젝트 구성

1. 이벤트 발행 (A 도메인)

@Service
public class OrderService {
    private final ApplicationEventPublisher eventPublisher;

    public OrderService(ApplicationEventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }

    public void placeOrder(Order order) {
        eventPublisher.publishEvent(new OrderPlacedEvent(order.getId()));
    }
}

2. 이벤트 구독 (B 도메인)

@Component
public class PaymentEventListener {
    @EventListener
    public void handleOrderPlaced(OrderPlacedEvent event) {
        System.out.println("Received order event: " + event.getOrderId());
    }
}

(C) 평가

• 장점: 서비스 간 결합도를 줄일 수 있다.
• 단점: 이벤트 순서 문제를 고려해야 한다.
• 대안: 메시지 브로커를 활용하여 처리 순서를 관리할 수 있다.