도메인 모델 패턴 vs 트랜잭션 스크립트 패턴

🔥 도메인 모델 패턴이란?

도메인 모델 패턴(Domain Model Pattern)은 애플리케이션의 비즈니스 로직을 도메인 객체(엔티티) 내부에 포함시키는 설계 패턴입니다. 즉, 비즈니스 규칙, 데이터 변경, 데이터 검증 등을 도메인 객체가 직접 수행하도록 설계합니다.

이 패턴은 DDD(Domain-Driven Design)의 핵심 개념 중 하나이며, 객체지향의 장점을 최대한 활용합니다.

특징

1. 도메인 객체에 책임 부여:객체가 자신의 상태를 관리하고, 관련된 비즈니스 로직을 수행합니다.
2. 예: Order 객체가 주문 생성, 주문 취소 등을 수행.
3. 비즈니스 로직의 캡슐화:데이터와 이를 처리하는 로직이 한 객체 내부에 캡슐화됩니다.
4. 엔티티 중심 설계:엔티티 객체가 단순히 데이터를 저장하는 역할만 하지 않고, 비즈니스 로직을 담고 있습니다.

도메인 모델 패턴의 구조

1. 엔티티(Entity)

애플리케이션의 비즈니스 로직과 데이터를 캡슐화합니다.

예: Order, Member, Product 등.

2. 밸류(Value Object)

특정 값을 표현하는 객체로, 값 자체가 중요하며 불변성을 가집니다.

예: Address, Money 등.

3. 애그리게이트(Aggregate)

엔티티와 밸류 객체가 하나로 묶인 집합입니다.

애그리게이트 루트(주로 엔티티)가 외부와의 상호작용을 담당하며, 내부 구성 요소를 관리합니다.

도메인 모델 패턴의 장점

• 객체지향의 장점 활용: 데이터와 행위를 하나의 객체로 묶어 객체지향적 설계를 촉진합니다.
• 비즈니스 로직 집중화: 비즈니스 로직이 객체에 집중되어 코드를 이해하기 쉽습니다.
• 응집도 향상: 관련된 로직과 데이터가 한 곳에 모여 유지보수가 쉬워집니다.
• 중복 코드 감소: 객체가 상태를 스스로 관리하므로, 서비스 계층의 로직 중복을 줄일 수 있습니다.

도메인 모델 패턴의 단점

• 초기 설계 비용: 도메인 모델을 설계하고 구현하는 데 많은 시간이 필요합니다.
• 복잡성 증가: 객체 간 관계와 비즈니스 로직이 복잡할 경우, 관리가 어려워질 수 있습니다.
• 숙련된 개발자 필요: 객체지향 설계와 도메인 주도 설계(DDD)에 대한 깊은 이해가 필요합니다.

예시: Order 클래스

@Entity
public class Order {

    @Id
    @GeneratedValue
    private Long id;

    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List orderItems = new ArrayList<>();

    @OneToOne(cascade = CascadeType.ALL)
    private Delivery delivery;

    private LocalDateTime orderDate;

    @Enumerated(EnumType.STRING)
    private OrderStatus status; // 예: ORDERED, CANCELED

    //== 비즈니스 로직 ==//

    // 주문 생성
    public static Order createOrder(Member member, Delivery delivery, OrderItem... orderItems) {
        Order order = new Order();
        order.setMember(member);
        order.setDelivery(delivery);
        for (OrderItem orderItem : orderItems) {
            order.addOrderItem(orderItem);
        }
        order.setOrderDate(LocalDateTime.now());
        order.setStatus(OrderStatus.ORDERED);
        return order;
    }

    // 주문 취소
    public void cancel() {
        if (delivery.getStatus() == DeliveryStatus.COMPLETE) {
            throw new IllegalStateException("이미 배송 완료된 주문은 취소할 수 없습니다.");
        }
        this.setStatus(OrderStatus.CANCELED);
        for (OrderItem orderItem : orderItems) {
            orderItem.cancel(); // 주문상품도 취소
        }
    }

    // 총 주문 가격 계산
    public int getTotalPrice() {
        return orderItems.stream()
                .mapToInt(OrderItem::getTotalPrice)
                .sum();
    }
}

분석

1. createOrder 메서드

정적 메서드로 주문을 생성하며, Member, Delivery, OrderItem을 설정합니다.

주문 생성 과정에서의 복잡한 로직을 캡슐화하여 서비스 계층을 단순화합니다.

2. cancel 메서드

주문 상태를 취소로 변경하며, 연관된 OrderItem도 취소합니다.

비즈니스 규칙(예: 배송 완료 후 취소 불가)을 캡슐화합니다.

3. getTotalPrice 메서드

주문상품의 총 가격을 계산합니다.

모든 계산 로직이 Order 내부에 있으므로, 외부에서 계산 로직을 알 필요가 없습니다.

서비스 계층의 단순화

도메인 모델 패턴을 사용하면 서비스 계층의 코드가 간결해집니다.

// 서비스 계층
@Transactional
public Long order(Member member, Delivery delivery, OrderItem... orderItems) {
    Order order = Order.createOrder(member, delivery, orderItems);
    orderRepository.save(order);
    return order.getId();
}

서비스 계층에서는 비즈니스 로직을 수행하는 대신, 도메인 객체를 조합하고 저장하는 역할만 수행합니다.

도메인 모델 패턴과 JPA

JPA는 엔티티 객체를 관리하며, 도메인 모델 패턴과 잘 맞습니다.

특히 JPA의 영속성 컨텍스트를 활용하면, 도메인 객체가 상태를 변경하더라도 JPA가 이를 감지하고 자동으로 데이터베이스에 반영합니다.

도메인 모델 패턴의 활용

1. 적합한 경우

• 비즈니스 로직이 복잡하고, 객체 간 관계가 많은 도메인.
• 코드의 재사용성과 응집도가 중요한 대규모 애플리케이션.

2. 적합하지 않은 경우

• 간단한 CRUD 애플리케이션.
• 비즈니스 로직이 단순한 경우, 트랜잭션 스크립트 패턴이 더 적합할 수 있습니다.

---

 

🔥 트랜잭션 스크립트 패턴 예시

트랜잭션 스크립트 패턴은 비즈니스 로직을 엔티티가 아닌 서비스 계층에서 처리하는 방식입니다.

이 패턴은 단순한 비즈니스 로직과 CRUD 작업에 적합하며, 도메인 모델 패턴보다 구현이 간단합니다.

1. 엔티티 간소화

엔티티 클래스는 데이터를 저장하고 가져오는 역할만 수행하며, 비즈니스 로직이 없습니다.

@Entity
public class Order {

    @Id
    @GeneratedValue
    private Long id;

    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List orderItems = new ArrayList<>();

    @OneToOne(cascade = CascadeType.ALL)
    private Delivery delivery;

    private LocalDateTime orderDate;

    @Enumerated(EnumType.STRING)
    private OrderStatus status; // 예: ORDERED, CANCELED

    // Getter, Setter만 존재
    public void addOrderItem(OrderItem orderItem) {
        this.orderItems.add(orderItem);
        orderItem.setOrder(this);
    }
}

2. 서비스 계층에서 모든 비즈니스 로직 처리

@Service
@Transactional
public class OrderService {

    private final OrderRepository orderRepository;
    private final MemberRepository memberRepository;

    public OrderService(OrderRepository orderRepository, MemberRepository memberRepository) {
        this.orderRepository = orderRepository;
        this.memberRepository = memberRepository;
    }

    // 주문 생성
    public Long createOrder(Long memberId, Delivery delivery, List orderItems) {
        // 회원 조회
        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> new IllegalArgumentException("회원이 존재하지 않습니다."));

        // 주문 생성
        Order order = new Order();
        order.setMember(member);
        order.setDelivery(delivery);
        for (OrderItem orderItem : orderItems) {
            order.addOrderItem(orderItem);
        }
        order.setOrderDate(LocalDateTime.now());
        order.setStatus(OrderStatus.ORDERED);

        // 주문 저장
        orderRepository.save(order);
        return order.getId();
    }

    // 주문 취소
    public void cancelOrder(Long orderId) {
        Order order = orderRepository.findById(orderId)
                .orElseThrow(() -> new IllegalArgumentException("주문이 존재하지 않습니다."));

        if (order.getDelivery().getStatus() == DeliveryStatus.COMPLETE) {
            throw new IllegalStateException("이미 배송 완료된 주문은 취소할 수 없습니다.");
        }

        // 상태 변경
        order.setStatus(OrderStatus.CANCELED);

        // 주문상품 취소
        for (OrderItem orderItem : order.getOrderItems()) {
            orderItem.cancel(); // 주문상품 취소 로직 호출
        }
    }

    // 총 주문 가격 계산
    public int getTotalPrice(Long orderId) {
        Order order = orderRepository.findById(orderId)
                .orElseThrow(() -> new IllegalArgumentException("주문이 존재하지 않습니다."));
        return order.getOrderItems().stream()
                .mapToInt(OrderItem::getTotalPrice)
                .sum();
    }
}

트랜잭션 스크립트 패턴의 특징

• 엔티티는 단순히 데이터와 관계를 표현하는 역할만 수행.
• 비즈니스 로직은 모두 서비스 계층에서 처리.
• 데이터 흐름이 간단한 프로젝트에서 효과적.

도메인 모델 패턴과 비교

특징	도메인 모델 패턴	트랜잭션 스크립트 패턴
로직 위치	엔티티 내부 (도메인 객체)	서비스 계층
비즈니스 로직 복잡도	복잡한 비즈니스 로직에 적합	간단한 CRUD 및 비즈니스 로직에 적합
유지보수	객체지향적 설계로 응집도가 높음	구조가 단순하지만 비즈니스 로직이 분산될 수 있음
재사용성	엔티티 로직을 재사용하기 용이	서비스 계층에서 같은 로직이 반복될 가능성 있음
설계 및 구현	초기 설계 비용이 큼	구현이 간단하고 빠름

결론

트랜잭션 스크립트 패턴은 단순한 애플리케이션에 적합하며, 비즈니스 로직이 복잡하지 않을 때 빠르고 효율적인 선택입니다.

하지만 로직이 복잡해지거나 재사용성이 중요해진다면 도메인 모델 패턴으로 전환을 고려해야 합니다.