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

도메인 모델 패턴

비즈니스 로직 대부분이 entity 내부에 위치하여 각 객체에 객체가 수행해야 하는 업무를 분담

(객체 지향의 특성을 적극 활용)

Service 계층은 단순히 entity에 필요한 요청을 위임하는 역할

 

(예시) 주문 취소 시

배송 상태 유효성 체크 및 상품 재고 원복이 필요할 때

OrderService의 주문 취소 기능 로직  ↓order.cancel()↓

Order (entity) 내부의 주문 취소 시 비즈니스 로직 ↓orderItem.cancel()↓

OrderItem (entity) 내부의 주문 취소 시 비즈니스 로직 ↓getItem().addStock(count)↓

Item (entity) 내부의 비즈니스 로직

위 예시 처럼 데이터를 가지고 있는 entity 안에서 관련 핵심 비즈니스 로직이 붙는게 응집력 있음

재사용성이 뛰어나지만, entity간의 설계가 수반되어야하기 때문에 모델 구축 시, 객체 간의 관계를 잘 풀어야 함

→ 특히 객체 사이의 dependency는 제약사항이 되기 때문에 설계가 매우 중요

 

---

 

트랜잭션 스크립트 패턴

entity에는 비즈니스 로직이 거의 없고(getter/setter 정도만 구현)

Service 계층에서 하나의 트랜잭션 안에서 필요한 대부분의 비즈니스 로직을 처리

 

(예시) 주문 취소 시

배송 상태 유효성 체크 및 상품 재고 원복이 필요할 때

OrderService의 주문 취소 기능 로직

구현이 쉽고 하나의 강건한 로직이 하나의 모듈에서만 동작해야할 경우 사이드 이펙트를 예방할 수 있음

하지만 구조가 복잡해질수록 모듈화의 복잡도 역시 올라가며, 코드 중복이 발생함

 

 

---

 

두 패턴 모두 각각의 장단점을 갖고 있으므로, 적절히 분배해서 사용하는 것이 좋음