헥사고날 아키텍처에서 Port vs CQRS 패턴 비교

 

 

헥사고날 아키텍처의 Application Layer를 구성할 때는
전통적인 Input/Output Port 방식과 CQRS를 적용한 방식의 실무적 차이점과 선택 기준을 고려해볼 수 있다.

 

단순 Input/Output Port는 하나의 비즈니스 로직에서 읽기와 쓰기를 모두 처리하는 전통적 방식이며
CQRS 적용은 Command(쓰기)와 Query(읽기)를 명확히 분리하여 각각 최적화할 수 있는 구조이다.
실무에서는 도메인 복잡도와 성능 요구사항에 따라 선택한다.

단순 CRUD 중심이면 Input/Output Port로 충분하고,
복잡한 비즈니스 로직과 조회 최적화가 필요하면 CQRS를 고려해볼만 하다.

 

 

 

실무 예시

1. 단순 Input/Output Port 구조

디렉토리 구조

application/
├── port/
│   ├── in/
│   │   └── OrderUseCase.java
│   └── out/
│       ├── LoadOrderPort.java
│       └── SaveOrderPort.java
└── service/
    └── OrderService.java

 

 

 

코드 예시

// Input Port - 비즈니스 유스케이스 정의
public interface OrderUseCase {
    OrderResponse createOrder(CreateOrderCommand command);
    OrderResponse getOrder(Long orderId);
    OrderResponse updateOrderStatus(Long orderId, OrderStatus status);
}

// Service - 읽기/쓰기 혼재
@Service
@RequiredArgsConstructor
public class OrderService implements OrderUseCase {
    private final LoadOrderPort loadOrderPort;
    private final SaveOrderPort saveOrderPort;
    
    @Transactional
    public OrderResponse createOrder(CreateOrderCommand command) {
        // 쓰기 로직
        Order order = Order.create(command);
        saveOrderPort.save(order);
        
        // 읽기 로직 (생성 후 조회)
        return OrderResponse.from(order);
    }
    
    @Transactional(readOnly = true)
    public OrderResponse getOrder(Long orderId) {
        // 읽기 로직
        Order order = loadOrderPort.loadById(orderId);
        return OrderResponse.from(order);
    }
}

 

 

 

2. CQRS 패턴 적용 구조

디렉토리 구조

application/
├── port/
│   ├── in/
│   │   ├── command/
│   │   │   ├── CreateOrderUseCase.java
│   │   │   └── UpdateOrderStatusUseCase.java
│   │   └── query/
│   │       ├── GetOrderQuery.java
│   │       └── SearchOrdersQuery.java
│   └── out/
│       ├── command/
│       │   └── OrderCommandPort.java
│       └── query/
│           └── OrderQueryPort.java
└── service/
    ├── command/
    │   └── OrderCommandService.java
    └── query/
        └── OrderQueryService.java

 

코드 예시

// Command Port - 쓰기 전용
public interface CreateOrderUseCase {
    OrderId execute(CreateOrderCommand command);
}

// Query Port - 읽기 전용
public interface GetOrderQuery {
    OrderDetailView execute(Long orderId);
}

// Command Service - 비즈니스 로직 집중
@Service
@RequiredArgsConstructor
public class OrderCommandService implements CreateOrderUseCase {
    private final OrderCommandPort commandPort;
    
    @Transactional
    public OrderId execute(CreateOrderCommand command) {
        // 도메인 로직에만 집중
        Order order = Order.create(command);
        commandPort.save(order);
        return order.getId();
    }
}

// Query Service - 조회 최적화
@Service
@RequiredArgsConstructor
public class OrderQueryService implements GetOrderQuery {
    private final OrderQueryPort queryPort; // QueryDSL, Native Query 가능
    
    @Transactional(readOnly = true)
    public OrderDetailView execute(Long orderId) {
        // DTO 직접 반환으로 성능 최적화
        return queryPort.findOrderDetailById(orderId);
    }
}

 

 

 

 

 

 

Port vs CQRS 패턴 상세 비교

왜 분리하는가?

1. 책임의 명확성

• Input/Output: UseCase가 읽기/쓰기 모두 담당하여 책임이 혼재
• CQRS: Command는 상태 변경만, Query는 조회만 담당하여 단일 책임 원칙 준수

 

2. 성능 최적화

// Input/Output: Entity 기반 조회
Order order = loadOrderPort.loadById(orderId);
// → 불필요한 연관관계 로딩 가능성

// CQRS: DTO 직접 조회
OrderDetailView view = queryPort.findOrderDetailById(orderId);
// → 필요한 컬럼만 SELECT, JOIN 최적화

 

3. 확장성

• Input/Output: 조회 로직 복잡도 증가 시 Service가 비대해짐
• CQRS: Query Service 독립 확장, 읽기 전용 DB 분리 가능

 

실무 선택 기준

1. Input/Output Port 적합한 경우

• 단순 CRUD 도메인 (사용자 관리, 설정 관리)
• 조회와 수정이 1:1 대응
• 팀 규모가 작고 빠른 개발 필요
• 트래픽이 낮고 성능 요구사항 단순

예시: 사내 관리자 도구, 설정 관리 시스템

2. CQRS 적합한 경우

• 복잡한 비즈니스 로직 (주문, 결제, 정산)
• 조회 요구사항이 다양하고 복잡 (대시보드, 리포트)
• 읽기/쓰기 비율 차이 큼 (읽기 90%, 쓰기 10%)
• 이벤트 소싱과 함께 사용

예시: 이커머스 주문 시스템, 광고 데이터 수집 플랫폼

 

주의사항

Input/Output Port

• Service 비대화 경고: 메서드 10개 이상 시 분리 고려
• 트랜잭션 범위 혼동: readOnly 트랜잭션 누락 주의
• Output Port 과도한 분리: LoadPort, SavePort를 Repository로 통합 고려

CQRS

• 과도한 분리: 단순 도메인에 적용 시 오버엔지니어링
• 코드 중복: Command/Query 간 유사 로직 발생 가능
• 학습 곡선: 팀원 모두가 패턴 이해 필요

 

 

결론

패턴 적용에 정답은 없으며, 실무에서는 도메인 복잡도와 성능 요구사항에 따라 선택함.
프로젝트 초기에는 Input/Output Port로 시작하고, 도메인 복잡도가 증가하거나 조회 성능 이슈 발생 시 CQRS로 점진적 전환하는 것이 안전함!