JPA 강의를 수강 중 강사님은 엔티티 자체가 해결할 수 있는 것은 엔티티 안에 비즈니스 로직을 넣는 것을 추천하셨다.
그러나 각 패턴의 장단점이 있기때문에 상황에 맞게 적절한 방법을 선택하는 것이 중요하다고 하셨다.
관련 강의 질문

그럼 두 패턴의 정의와 패턴의 장단점을 정리하고, 어떤 상황에 어떤 패턴을 적용해야 하는지 대해 정리해보겠다.

도메인 모델 패턴

엔티티 자체가 비즈니스 로직을 포함하고 이를 통해 상태를 변경하는 방식이다. 이 패턴은 주로 도메인 주도 설계(DDD)에서 사용된다.

장점

• 응집도가 높다.
  : 관련된 로직과 데이터가 한 곳에 모여 유지보수가 쉬워진다.
• 유지보수성과 확장성이 뛰어나다.
• information expert pattern을 지키면서 개발할 수 있다.

  information expert pattern
  책임을 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것이다.
  이 패턴을 따르면 정보와 행동을 최대한 가까운 곳에 위치시키기 때문에 캡슐화를 유지할 수 있다.

단점

• 복잡한 도메인 설계 필요
  : 도메인 모델 패턴은 도메인에 맞춘 정교한 설계를 요구하기 때문에, 복잡한 구조가 될 수 있다. 이로 인해 개발 속도가 저하될 가능성도 있다.

예시

@Entity
@Getter
@Setter
@Table(name = "orders")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Order {
...
public void cancel() {
        if (delivery.getStatus() == DeliveryStatus.COMP) {
            throw new IllegalStateException("이미 배송완료된 상품은 취소가 불가능합니다.");
        }

        this.setStatus(OrderStatus.CANCEL);
        for (OrderItem orderItem : orderItems) {
            orderItem.cancel();
        }
    }
 }
}

→ 주문 취소 로직 같은 경우 엔티티 내에서 직접 수행하고, 서비스 계층에서는 이를 호출하는 역할만 한다.

트랜잭션 스크립트 패턴

대부분의 비즈니스 로직을 서비스 계층에서 처리하고 엔티티는 단순히 getter, setter 정도만 제공한다.

장점

• 구현이 단순하다.
  : 로직을 단일 함수나 스크립트로 처리하기 때문에 코드가 간결하고 직관적이다.

단점

• 서비스 클래스가 너무 커질 수 있다.
• 객체지향 원칙 위배 가능성
  : 트랜잭션 스크립트 패턴은 주로 절차 지향적 접근을 따르기 때문에 객체지향적인 설계 원칙을 따르기 어렵다
• 테스트가 어려울 수 있다.
  : 단일 함수 내에서 복잡한 절차를 처리해야 하므로 단위 테스트가 제한적일 수 있다.

예시

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class OrderService {

    @Transactional
    public void cancelOrder(Long orderId) {
        Order order = orderRepository.findOne(orderId);

        if (order.getStatus() == OrderStatus.CANCEL) {
            throw new IllegalStateException("이미 취소된 주문입니다.");
        }

        order.setStatus(OrderStatus.CANCEL);
        orderRepository.save(order);
    }
}

→ 서비스 계층에서는 엔티티에 getter를 사용하여 데이터를 가져와서 비교하고 직접 엔티티의 상태를 변경한다.

어떤 패턴을 선택해야 할까?

• 도메인 모델 패턴: 도메인이 복잡하고 비즈니스 로직이 핵심인 주문 시스템이나 금융 서비스
• 트랜잭션 스크립트 패턴: 단순 CRUD 서비스

---

참고
실전! 스프링 부트와 JPA 활용1,
Information Expert Pattern,
Transaction Script Pattern