Spring Boot에서 DDD(Domain-Driven Design)를 실무에 적용하는 ‘진짜’ 방법

작성자:

1. 전략적 설계: 바운디드 컨텍스트(Bounded Context)의 획정

DDD의 시작은 코드가 아니라 ‘대화’와 ‘경계’입니다. 서로 다른 도메인이 섞이지 않도록 바운디드 컨텍스트를 서비스 간에 명확히 나누고, 개발자와 비즈니스 전문가가 동일한 언어로 소통하는 ‘보편적 언어(Ubiquitous Language)’를 구축해야 합니다.

Strategic Design: Overlapping Bounded Contexts with Ubiquitous Language
도메인 주도 설계를 위한 전략적 설계와 바운디드 컨텍스트 개념

Pro-tip: 컨텍스트 매핑(Context Mapping)을 통해 각 서비스 간의 상호작용 방식(고객-공급자, 공유 커널 등)을 먼저 정의하세요. 이는 마이크로서비스 아키텍처로의 전환 시 핵심 자산이 됩니다.

2. 전술적 설계: 풍부한 도메인 모델(Rich Domain Model) 구현

단순히 데이터만 담고 있는 Anemic Domain Model(빈약한 도메인 모델)은 객체지향의 장점을 살리지 못합니다. 비즈니스 규칙은 도메인 객체(Entity, Value Object) 내부로 숨기고, 서비스 레이어는 오케스트레이션 역할만 수행해야 합니다.

The ‘Bad’ Way: Anemic Domain Model (Logic in Service)

// 서비스 레이어에 비즈니스 로직이 몰려 있는 경우 (유지보수 지옥)
public void updateOrder(Long orderId, int amount) {
    Order order = repository.findById(orderId);
    if (order.getStatus() == OrderStatus.SHIPPED) {
        throw new IllegalStateException("이미 배송된 주문은 수정할 수 없습니다.");
    }
    order.setAmount(amount);
}

The ‘ELITE’ Way: Rich Domain Model (Logic in Entity)

// 도메인 객체가 스스로의 규칙을 관리 (객체지향적)
public class Order {
    public void changeAmount(int amount) {
        validateChangeable();
        this.amount = amount;
    }
    private void validateChangeable() {
        if (status == OrderStatus.SHIPPED) throw new BusinessException("...");
    }
}

3. 헥사고날 아키텍처: 도메인을 기술로부터 보호하기

도메인은 데이터베이스나 외부 API 같은 외부 기술에 의존해서는 안 됩니다. **헥사고날 아키텍처(포트와 어댑터 패턴)**를 적용하여 도메인을 중앙에 두고, 외부 기술을 어댑터로 분리하면 기술 변경에도 도메인 핵심 로직은 변하지 않습니다.

Hexagonal Architecture: Ports and Adapters Strategy
도메인을 기술로부터 독립시키는 헥사고날 아키텍처 구조

4. 실전 적용: 애그리거트(Aggregate)와 일관성 경계

객체들이 너무 촘촘하게 연결되면 한 객체를 수정할 때 시스템 전체가 흔들립니다. 관련된 객체들을 **애그리거트**라는 단위로 묶고, 애그리거트 루트(Root)를 통해서만 접근하도록 제한하여 데이터의 일관성과 트랜잭션 경계를 명확히 관리하세요.

Rich Domain Model and Aggregates Concept
복잡한 도메인 논리를 관리하는 풍부한 도메인 모델 구성

5. 점진적인 도입 전략

기존의 거대한 모놀리스 시스템을 한꺼번에 DDD로 바꾸는 것은 불가능에 가깝습니다. 핵심 비즈니스 가치가 높은 모듈부터 ‘Anti-Corruption Layer(부패 방지 레이어)’를 구축하며 점진적으로 기술적 부채를 해결해 나가야 합니다.

Lesson Learned: DDD는 도구가 아니라 철학입니다. 지나치게 복잡한 패턴(Event Sourcing, CQRS 등)을 처음부터 도입하기보다, 도메인 핵심 가치를 코드로 표현하는 것에서부터 시작하세요.

결론: 비즈니스를 담는 그릇, DDD

복잡한 코드를 정돈하고 비즈니스의 변화에 유연하게 대응할 수 있는 시스템을 만드는 것, 그것이 바로 ‘ELITE’ 개발자가 DDD를 공부해야 하는 이유입니다. Spring Boot의 강력한 기능과 DDD의 설계를 결합하여, 시간이 흘러도 가치를 더해가는 견고한 애플리케이션을 구축하시길 응원합니다.

댓글 남기기