🚀 DDD 기반 주문 생성 프로세스 설계: Facade와 도메인 서비스 분리 여정

주문 생성 트랜잭션을 깔끔하고 유지보수하기 쉬운 코드로 만들기 위해, 기능과 책임을 쪼개고 합치는 여정의 기록입니다. 이 과정에서 응용 서비스(Facade)와 도메인 서비스의 경계를 명확히 했습니다.

1. 🔍 초기 분석: 주문 트랜잭션의 4단계

구현해야하는 기능을 문장으로,
"주문자가 / 재고가 있는 상품을 / 충분한 포인트로 결재하여 / 주문을 생성한다."

1. 문장에서 필요한 도메인(대상)은?
   1) 사용자
   2) 상품(주문에 필요한 자원)
   3) 포인트(주문에 필요한 자원)
   4) 주문

2. 어떤 순서로 진행되어야 하는가?
   1) 주문에 필요한 도메인이 진짜 있는가?
   2) 주문에 필요한 자원은 확보하였는가?
   3) 자원을 사용한다.
   4) 주문을 생성한다.

📋 주문 생성 프로세스 단계 (DDD 관점)

순서	명칭	핵심 행위	관련 도메인 엔티티
1	확인 (Active)	사용자, 상품, 포인트가 존재하는가?	User, Product, Point
2	검증 (Validate)	재고/잔액 조건이 충분한가?	Product, Point
3	실행 (Execute)	재고 차감, 포인트 차감 (상태 변경)	Product, Point
4	생성 (Create)	최종 주문 객체 생성 및 저장	Order

1.1. 확인: 도메인 정보 조회 (Read-Only)

주문 생성이 가능한 활성 상태인지 확인합니다.

• userService.getActiveUser(Long userId)
• productService.getExistProducts(List<Long> productIds)
• pointService.getAvailablePoints(Long userId) (포인트는 경우에 따라 필수X)

1.2. 검증 & 실행: 필요한 데이터 정의

가장 복잡한 재고/포인트의 검증 및 차감은 다음 데이터를 필요로 합니다.

자원	현재 상태 (도메인)	필요 수량/금액 (요청)
재고	List<Product> (현재 재고)	Map<Long, Long> (상품 ID → 수량)
포인트	Point 또는 User	SUM(상품 가격 x 수량)

1.3. 실행

전 단계의 이름과 특징을 적어보자

1) 확인

• 유저 정보 (DB 조회)
• 상품 정보 (DB 조회)
• 포인트 정보 (DB 조회)

userService.getActiveUser(Long `사용자ID`)
productService.getExistProducts(List <Long\> `상품IDs`)
pointService.getAvailablePoints(Long `사용자ID`)

2) 재고차감

• 필요한 재고 검증
• 재고차감(트랜잭션)

verifyProductStock(List <Product\> `현재재고`, List<Long 상품ID ,Long 수량\> `필요한 재고`)
deductProductStock(List<Product\> `현재재고`, List<Long 상품ID,Long 수량\> `필요한 재고`)

3) 포인트차감

• 충분한 포인트 검증
• 포인트 차감(트랜잭션)

verifyPointBalance(Point `현재 포인트`, `? 필요한 포인트`)
useUserPoint(Point `현재 포인트`, `? 필요한 포인트`)

4) 주문서 생성(트랜잭션)

createOrder(Order)

2. 🧱 설계 시도와 핵심 결정

결정 1: DB 조회와 트랜잭션이 일어나는 기능은 Application service, 그 외는 Domain service

결정 2: 검증과 차감은 한번에

verify(검증) 후 deduct(차감) 을 분리하는 대신, 하나의 도메인 서비스 내에서 검증과 상태 변경(차감)을 하나의 행위로 통합했습니다. 입력값이 동일하며, 리스트 확인 및 데이터 수정으로 중복 조회가 일어나기 때문에 이를 방지하기 위해서 입니다.

결정 3: Map<Long, Long>으로 데이터 표준화

public class OrderCreateV1Dto {
  public record OrderItemRequest(long productId, long quantity) {
  }
  public record OrderRequest(List<OrderItemRequest> items) {
  }
}

재고데이터 List<Product> 와 요청받은 List<OrderItemRequest> 주문내역을 비교하기 위해서, List<OrderItemRequest> 를 중복을 제거한 Map<Long,Long> 형식으로 변경하여 productId를 키값으로 수량검색이 용이하도록 했습니다.

public record CreateOrderCommand(Long userId, Map<Long, Long> orderItemInfo) {
  public record ItemCommand(Long productId, Map<Long, Long> quantity) {
  }
}

지금까지의 결정을 반환 타입까지 포함해서 적어보면,

UserService.getActiveUser(Long userId)->User
ProductService.getExistProducts(List<Long>)->List<Product>
PointService.getAvailablePoints(Long userId)->Point
 
verifyProductStock(List<Product> 현재재고, Map<Long 상품ID ,Long 수량> 필요한재고)-> `재고를 차감한 List<Product>`
deductProductStock(List<Product> 현재재고, Map<Long 상품ID,Long 수량> 필요한 재고)

verifyPointBalance(Point 현재 포인트, List<Product> 가격,Map<Long,Long> 수량) -> `사용 포인트를 차감한 Point`
saveUserPoint(Point 현재 포인트, `필요한 포인트`)

createOrder(Order)-> Order

결정 4: verifyPointBalance에서 차감된 포인트가 아닌 총 가격를 반환하자.

시도 1: verifyPointBalance 에서 포인트를 차감하고 잔액 Point를 반환하자?

verifyPointBalance으로( Point, List<Product>, Map<Long,Long>)을 보내고, Point 에서 총가격을 뺀 남은 Point 를 리턴하고 그대로 Point 를 저장하자.

포인트 차감후, 주문 생성에 필요한 데이터는?

• Order: 유저ID, 총 가격

• OrderItem: 상품ID, 수량, 단가

  총가격을 비교하는 verifyPointBalance에서 차감된 잔액 포인트가 리턴된다. 따라서 어디서도 총가격을 저장하고 있지 않아, 검증 이후 총 가격을 다시 구해야 한다. verifyPointBalance 에서 차감된 포인트가 아닌 총가격을 반환하자.

Order Facade에서 정리하면,

OrderFacade {
  public OrderInfo createOrder(CreateOrderCommand command) {
  User user = UserService.getActiveUser(Long userId);
  List<Product> products = ProductService.getExistProducts(List<Long> productIds);
  Point point = PointService.getAvailablePoints(Long userId);
  
  List<Product> deductedProducts = OrderPreparer.verifyProductStock(List<Product> products, List<Long 상품ID ,Long 수량> command.getOrderItemCommand);
  deductProductStock(deductedProducts)
  
  BigDecimal requestedPoints = OrderPreparer.verifyPointBalance(Point 현재 포인트, List<Product> 가격,Map<Long,Long> 수량);
  saveUserPoint(Point 현재 포인트 - requestedPoints)

  Order order = createOrder(User,List<Product>,Point)
  return OrderInfo.from(savedOrder);
  }

결정 5: 주문 생성시, 총가격 대신 Map<Long 상품ID ,Long 수량>

주문 상세 데이터 생성을 위해 상품의 단가,수량을 알려면 Map<Long 상품ID ,Long 수량> 를 넣어야 하고, List 만들면서 총가격을 계산할수 있기 때문에, 총가격 대신 Map<Long 상품ID ,Long 수량> 을 넣기로 했습니다.

결정 6: 포인트 저장 대신 포인트 차감

차감한 포인트를 저장하려다가, "포인트를 저장한다" 대신 "포인트를 차감한다" 의 의미가 행동의 의미를 잘 담고 있는것 같아서, verifyPointBalance 대신, 총가격을 조회하는 함수로 바꾸기로 했습니다.

@Transactional
  public OrderInfo createOrder(CreateOrderCommand command) {
    Map<Long, Long> quantityMap = command.orderItemInfo();
    User user = userService.getActiveUser(command.userId());
    List<Product> productList = productService.getExistingProducts(quantityMap.keySet());
    Point point = pointService.getAvailablePoints(user.getId());

    List<Product> deductedProducts = OrderPreparer.verifyProductStock(productList, quantityMap);
    productService.save(deductedProducts);

    BigDecimal totalAmt = OrderPreparer.getTotalAmt(point, productList, quantityMap);
    pointService.use(user, totalAmt);
    
    Order savedOrder = createOrderService.save(user, productList, quantityMap);

    return OrderInfo.from(savedOrder);
  }

결정 7:verify(검증) 후 **deduct(실행)을 합치자

같은 파라미터를 쓰고 있는 재고검증 및 차감 과 포인트검증 및 차감을 productStockService,userPointService로 합쳤습니다.

@Transactional
  public OrderInfo createOrder(CreateOrderCommand command) {
    Map<Long, Long> quantityMap = command.orderItemInfo();
    User user = userService.getActiveUser(command.userId());
    List<Product> productList = productService.getExistingProducts(quantityMap.keySet());
    
    productStockService.deduct(productList, quantityMap);
    userPointService.use(user, productList, quantityMap);

    Order savedOrder = createOrderService.save(user, productList, quantityMap);
    return OrderInfo.from(savedOrder);
  }

💡 정리 및 결론

처음 복잡하게 느껴졌던 주문 생성 로직이, 책임(재고, 포인트)을 기준으로 도메인 서비스(Manager)를 분석하고, 최종적으로 간결하고 이해하기 쉬운 형태의 OrderFacade를 만들어내었습니다. 추가로,초기 모델의 존재여부를 확인하는 부분도 한번 합쳐보면 더 보기좋은 코드가 될것 같은데 이렇게 계속 합쳐도 되는지, 의문이 들기도 했습니다.