fos-blog/study
01 / 홈02 / 카테고리
01 / 홈02 / 카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • langgraph 페이지로 이동
    • agents.md
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code를 5주 더 쓴 결과 — 스킬·CLAUDE.md를 키워가는 방식
    • Claude Code를 11일 동안 쓴 결과 — 데이터로 본 나의 사용 패턴
    • Claude Code 멀티 에이전트 — Teams
    • AI 에이전트와 디자인의 새 컨벤션 — DESIGN.md, Google Stitch, Claude Design
    • 하네스 엔지니어링 실전 — 4인 에이전트 팀으로 코딩 파이프라인 구축하기
    • 하네스 엔지니어링 — 오래 실행되는 AI 에이전트를 위한 설계
    • 멀티모달 LLM (Multimodal Large Language Model)
    • AI 에이전트와 함께 MVP 만들기 — dooray-cli 사례
  • ai 페이지로 이동
    • agent 페이지로 이동
  • algorithm 페이지로 이동
    • live-coding 페이지로 이동
    • 분산 계산을 위한 알고리즘
  • architecture 페이지로 이동
    • [초안] 시니어 백엔드를 위한 API 설계 실전 스터디 팩 — REST · 멱등성 · 페이지네이션 · 버전 전략
    • [초안] API Versioning과 Backward Compatibility: 시니어 백엔드 관점 정리
    • 캐시 설계 전략 총정리
    • [초안] CJ푸드빌 커머스/F&B 도메인 설계 면접 대비 — 슬롯 경험을 주문·결제·쿠폰·매장 상태 설계로 번역하기
    • [초안] 커머스 Spring 서비스에 Clean/Hexagonal Architecture를 실용적으로 적용하기
    • [초안] 커머스 주문 상태와 데이터 정합성 기본기 — CJ푸드빌 면접 대비
    • [초안] 쿠폰/프로모션 동시성과 정합성 기본기 — 선착순·중복 사용 방지·발급/사용/복구
    • [초안] DDD와 도메인 모델링: 시니어 백엔드 관점의 전술/전략 패턴 실전 가이드
    • [초안] Decorator & Chain of Responsibility — 행동을 체인으로 조립하는 두 가지 방식
    • 디자인 패턴
    • [초안] 분산 아키텍처 완전 정복: Java 백엔드 시니어 인터뷰 대비 실전 가이드
    • [초안] 분산 트랜잭션과 Outbox 패턴 — 왜 2PC를 피하고 어떻게 대신할 것인가
    • 분산 트랜잭션
    • [초안] e-Commerce 주문·결제 도메인 모델링: 상태머신, 멱등성, Outbox/Saga 실전 정리
    • [초안] F&B 쿠폰·프로모션·멤버십·포인트 설계
    • [초안] F&B · e-Commerce 디지털 채널 도메인 한 장 정리 — CJ푸드빌 디지털 채널 백엔드 면접 대비
    • [초안] F&B 주문/매장/픽업 상태머신 설계 — CJ푸드빌 디지털 채널 백엔드 관점
    • [초안] F&B 이커머스 결제·환불·정산 운영 가이드
    • [초안] Hexagonal / Clean Architecture를 Spring 백엔드에 적용하기
    • [초안] 대규모 커머스 트래픽 처리 패턴 — 1,600만 고객과 올영세일을 버티는 설계
    • [초안] 레거시 JSP/jQuery 화면과 신규 API가 공존하는 백엔드 운영 전략
    • [초안] MSA 서비스 간 통신: Redis [Cache-Aside](../database/redis/cache-aside.md) × Kafka 이벤트 하이브리드 설계
    • [초안] Observability 입문: 시니어 백엔드가 장애를 탐지하고 대응하는 방식
    • [초안] Outbox / Inbox Pattern 심화 — 분산 메시징의 정합성 문제를 DB 트랜잭션으로 풀어내기
    • [초안] 결제 도메인 멱등성과 트랜잭션 재시도 기본기
    • [초안] 시니어 백엔드를 위한 Resilience 패턴 실전 가이드 — Timeout, Retry, Circuit Breaker, Bulkhead, Backpressure
    • [초안] REST API 버저닝과 모바일 앱 하위 호환성 — CJ푸드빌 디지털 채널 백엔드 관점
    • [초안] Strategy Pattern — 분기문을 없애는 설계, 시니어 백엔드 인터뷰 핵심 패턴
    • [초안] 시니어 백엔드를 위한 시스템 설계 입문 스터디 팩
    • [초안] 템플릿 메서드 패턴 - 백엔드 처리 골격을 강제하는 가장 오래되고 가장 위험한 패턴
    • [초안] 대규모 트래픽 중 무중단 마이그레이션 — Feature Flag + Shadow Mode 실전
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야 할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • [초안] JPA N+1과 커머스 조회 모델: 주문/메뉴/쿠폰 도메인에서 살아남기
    • [초안] MyBatis 기본기 — XML Mapper, resultMap, 동적 SQL, 운영 패턴 정리
    • [초안] MyBatis와 JPA/Hibernate 트레이드오프 — 레거시 백엔드를 다루는 시니어 관점
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • observability 페이지로 이동
    • [초안] 커머스/F&B 채널 장애 첫 5분과 관측성 기본기
    • Envoy Proxy
    • [초안] F&B / e-Commerce 운영 장애 대응과 모니터링 — 백엔드 관점 정리
    • Graceful Shutdown
  • finance 페이지로 이동
    • industry-cycle 페이지로 이동
    • investing 페이지로 이동
    • stock-notes 페이지로 이동
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • [초안] AI 서비스 팀 경험 기반 시니어 백엔드 면접 질문 뱅크 — Spring Batch RAG / gRPC graceful shutdown / 전략 패턴 / 12일 AI 웹툰 MVP
    • [초안] CJ푸드빌 디지털 채널 Back-end 개발자 직무 분석
    • [초안] CJ푸드빌 디지털 채널 Back-end 면접 답변집 — 슬롯 도메인 경험을 커머스/F&B 설계로 번역하기
    • [초안] F&B / e-Commerce 운영 모니터링과 장애 대응 인터뷰 정리
    • Observability — 면접 답변 프레임
    • [초안] 시니어 Java 백엔드 면접 마스터 플레이북 — 김병태
    • [초안] NSC 슬롯팀 경험 기반 질문 은행 — 도메인 모델링·동시성·성능·AI 협업
  • java 페이지로 이동
    • concurrency 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • [초안] Java 동시성 락 정리 — 커머스 메뉴/프로모션 정책 캐시 갱신 관점
    • [초안] JVM 튜닝 실전: 메모리 구조부터 Virtual Threads, GC 튜닝, 프로파일링까지
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node 백엔드 운영 패턴 — Streams 백프레셔, pipe/pipeline, 멱등성 vs 분산 락
    • Node.js
    • npm vs pnpm — 어떤 기준으로 선택했나
    • `setImmediate()`
  • kafka 페이지로 이동
    • [초안] Kafka 기본 개념 — 토픽, 파티션, 오프셋, 복제
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • [초안] Kafka 실전 설계: 파티션 전략, 컨슈머 그룹, 전달 보장, 재시도, 순서 보장 트레이드오프
    • 메시지 전송 신뢰성
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • rabbitmq 페이지로 이동
    • [초안] RabbitMQ Basics — 실전 백엔드 관점에서 정리하는 메시지 브로커 기본기
    • [초안] RabbitMQ vs Kafka — 백엔드 메시징 선택 기준과 실전 운영 관점
  • security 페이지로 이동
    • [초안] 시니어 백엔드를 위한 보안 / 인증 스터디 팩 — Spring Security, JWT, OAuth2, OWASP Top 10
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • sb-dev-team 페이지로 이동
    • the-future-company 페이지로 이동
  • testing 페이지로 이동
    • [초안] 시니어 Java 백엔드를 위한 테스트 전략 완전 정리 — 피라미드부터 TestContainers, 마이크로벤치, Contract까지
  • travel 페이지로 이동
    • 오사카 3박 4일 일정표: 우메다 쇼핑, USJ, 난바·도톤보리, 오사카성
  • web 페이지로 이동
    • [초안] HTTP / Cookie / Session / Token 인증 기본기 — 레거시 JSP와 모바일 API가 공존하는 백엔드 관점
FOS-BLOG · FOOTERall systems normal·v0.1 · 2026.04.27·seoul, kr
Ffos-blog/study

개발 학습 기록을 정리하는 블로그입니다. 공부하면서 기록하고, 기록하면서 다시 배웁니다.

visitors
01site
  • Home↗
  • Posts↗
  • Categories↗
  • About↗
02policy
  • 소개/about
  • 개인정보처리방침/privacy
  • 연락처/contact
03categories
  • AI↗
  • Algorithm↗
  • DB↗
  • DevOps↗
  • Java/Spring↗
  • JS/TS↗
  • React↗
  • Next.js↗
  • System↗
04connect
  • GitHub@jon890↗
  • Source repositoryjon890/fos-study↗
  • RSS feed/rss.xml↗
  • Newsletter매주 1 회 · 한 편의 글→
© 2026 FOS Study. All posts MIT-licensed.
built with·Next.js·Tailwind v4·Geist·Pretendard·oklch
fos-blog/architecture/[초안] 커머스 Spring 서비스에 Cle…
system

[초안] 커머스 Spring 서비스에 Clean/Hexagonal Architecture를 실용적으로 적용하기

CJ푸드빌 같은 외식·커머스 도메인은 표면적으로는 "메뉴 CRUD에 결제 붙이기"처럼 보이지만, 실제로는 매장 운영, 재고, 프로모션, 결제, 주문 상태 머신이 얽힌다. 이때 모든 로직을 @Service 한 클래스에 몰면 처음 6개월은 빠르지만, 1년 차부터는 결제 PG 교체, 재고 정책 변경, 주문 상태 추가가 수십 개의 if-else 가지를 수정해야 끝...

2026.05.09·10 min read·16 views

왜 중요한가

CJ푸드빌 같은 외식·커머스 도메인은 표면적으로는 "메뉴 CRUD에 결제 붙이기"처럼 보이지만, 실제로는 매장 운영, 재고, 프로모션, 결제, 주문 상태 머신이 얽힌다. 이때 모든 로직을 @Service 한 클래스에 몰면 처음 6개월은 빠르지만, 1년 차부터는 결제 PG 교체, 재고 정책 변경, 주문 상태 추가가 수십 개의 if-else 가지를 수정해야 끝나는 상태로 변한다. Clean Architecture와 Hexagonal Architecture(포트/어댑터)는 이런 도메인을 외부 기술이 바뀌어도 핵심 정책이 흔들리지 않게 분리하는 도구다.

다만 모든 화면을 헥사고날로 짜면 1주일 작업이 1달이 된다. 시니어 면접에서 묻는 핵심도 "다 짤 줄 아느냐"가 아니라 "어디까지 적용하고 어디서 멈추느냐"다. 이 글은 그 경계선을 잡는 실전 문서다.

핵심 개념: 의존성 방향만 기억하면 된다

Clean Architecture의 다이어그램은 네 겹이지만 본질은 한 줄이다.

외부(웹, DB, 메시징, PG)는 도메인을 안다. 도메인은 외부를 모른다.

Spring 표준 레이어드 아키텍처에서는 보통 다음과 같이 의존성이 흐른다.

plaintext
Controller → Service → Repository(JPA) → Entity(@Entity)

여기서 Service가 JpaRepository와 @Entity에 직접 의존하는 순간, "DB가 MySQL이라는 사실"이 비즈니스 정책 안으로 새어 들어온다. 헥사고날에서는 다음과 같이 바꾼다.

plaintext
[adapter-in]  HTTP Controller, Kafka Listener
       │
       ▼
[application] UseCase 인터페이스 ← 구현 ApplicationService
       │  ↓ 사용         ↑ 호출
       ▼
[domain]      Order, OrderLine, OrderPolicy (POJO)
       ▲
       │ 구현
[adapter-out] OrderJpaRepository, KafkaPublisher, TossPaymentClient
       │ implements
[application] OrderRepository(port), PaymentPort

즉 application 모듈은 자기보다 안쪽(domain)만 알고, 바깥쪽(adapter)은 인터페이스(port)로만 안다. Spring DI가 런타임에 어댑터를 꽂아준다.

커머스에서 어디까지 적용할지: CRUD vs 복잡 도메인

실용적으로 모든 Bounded Context에 같은 깊이로 적용하지 않는다. 보통 다음 기준으로 나눈다.

유형예시(외식 커머스)권장 스타일
단순 CRUD매장 영업시간 조회, 카테고리 마스터Transaction Script + JPA Repository 직결
흐름 위주메뉴 검색, 매장 목록Application Service + 얇은 도메인 객체
상태 머신/정책주문, 결제, 환불, 프로모션 적용헥사고날 + 도메인 모델 + 포트 분리
외부 통합 다수결제, 배달 라이더 호출, 매장 POS 연동포트/어댑터 강제, 어댑터 단위 통합 테스트 분리

CJ푸드빌처럼 "주문/결제/매장 운영"이 핵심이면 그 영역만 헥사고날로 가져가고 사이드 도메인(공지사항, 운영자 화면 일부)은 굳이 깊이 적용하지 않는다. 이 판단을 Pragmatic Clean Architecture라고 부르며, 면접에서 강조해야 할 부분이다.

DDD 전술 패턴 자체에 대한 더 깊은 정리는 별도 문서로 갈 가능성이 높으므로, 이 문서는 "Spring 코드 위에서 어떻게 모듈/패키지를 자르고 트랜잭션을 묶을지"에 집중한다.

패키지·모듈 구조 한 가지 안

멀티모듈로 가는 것이 이상적이지만, 단일 모듈에서도 패키지로 동일한 효과를 낼 수 있다. CJ푸드빌 같은 모놀리식 커머스에서 무난한 출발점은 다음 구조다.

plaintext
com.example.order
├── domain                  // POJO, 프레임워크 의존 0
│   ├── Order.java
│   ├── OrderLine.java
│   ├── OrderStatus.java
│   └── OrderPricingPolicy.java
├── application
│   ├── port.in
│   │   └── PlaceOrderUseCase.java
│   ├── port.out
│   │   ├── OrderRepository.java
│   │   ├── PaymentPort.java
│   │   └── StoreInventoryPort.java
│   └── service
│       └── PlaceOrderService.java   // @Service, @Transactional
└── adapter
    ├── in.web
    │   └── OrderController.java
    └── out
        ├── persistence
        │   ├── OrderJpaEntity.java
        │   ├── OrderJpaRepository.java
        │   └── OrderPersistenceAdapter.java   // implements OrderRepository
        ├── payment
        │   └── TossPaymentAdapter.java        // implements PaymentPort
        └── inventory
            └── StoreInventoryHttpAdapter.java

domain 패키지에는 Spring/JPA 어노테이션을 넣지 않는다. 이 규칙 하나만 ArchUnit으로 강제해도 효과가 크다.

java
@Test
void domainShouldNotDependOnSpringOrJpa() {
    noClasses().that().resideInAPackage("..order.domain..")
        .should().dependOnClassesThat()
        .resideInAnyPackage("org.springframework..", "jakarta.persistence..", "..adapter..")
        .check(importedClasses);
}

나쁜 예: 트랜잭션 스크립트로 뒤엉킨 주문 서비스

java
@Service
@RequiredArgsConstructor
public class OrderService {
 
    private final OrderJpaRepository orderRepo;
    private final MenuJpaRepository menuRepo;
    private final RestTemplate paymentClient;
    private final KafkaTemplate<String, String> kafka;
 
    @Transactional
    public Long placeOrder(PlaceOrderRequest req) {
        var menus = menuRepo.findAllById(req.menuIds());
        long total = 0;
        for (var m : menus) {
            if (m.getStoreId() != req.storeId()) {
                throw new IllegalArgumentException("매장 불일치");
            }
            if (req.couponCode() != null && m.isCouponApplicable()) {
                total += m.getPrice() * 9 / 10;
            } else {
                total += m.getPrice();
            }
        }
 
        var pgRes = paymentClient.postForObject(
            "https://pg.example.com/pay",
            Map.of("amount", total, "card", req.cardToken()),
            Map.class);
 
        if (!"OK".equals(pgRes.get("result"))) {
            throw new IllegalStateException("결제 실패");
        }
 
        var entity = new OrderJpaEntity(req.storeId(), total, "PAID", LocalDateTime.now());
        orderRepo.save(entity);
 
        kafka.send("order.created", String.valueOf(entity.getId()));
        return entity.getId();
    }
}

이 코드의 문제는 다음과 같다.

  • 가격 정책(쿠폰 10% 할인)과 PG 호출, 카프카 발행이 한 메서드 안에 섞여 있다.
  • RestTemplate 응답 형식이 바뀌면 비즈니스 로직 클래스가 흔들린다.
  • 단위 테스트하려면 카프카, PG, JPA를 모두 모킹해야 한다.
  • "결제 후 주문 저장 실패" 같은 정합성 시나리오를 검증할 자리가 없다.
  • PG가 토스에서 NICE로 바뀌면 같은 클래스를 다시 연다.

개선 예: 포트/어댑터 + 도메인 모델

도메인은 정책만 안다.

java
// domain/Order.java
public class Order {
    private final Long id;
    private final Long storeId;
    private final List<OrderLine> lines;
    private OrderStatus status;
    private Money totalAmount;
 
    public static Order place(Long storeId, List<OrderLine> lines, CouponPolicy coupon) {
        if (lines.isEmpty()) throw new DomainException("빈 주문");
        Money total = lines.stream()
            .map(line -> coupon.applyTo(line))
            .reduce(Money.ZERO, Money::plus);
        return new Order(null, storeId, lines, OrderStatus.PENDING, total);
    }
 
    public void markPaid() {
        if (status != OrderStatus.PENDING) throw new DomainException("이미 처리됨");
        this.status = OrderStatus.PAID;
    }
}

application 계층은 유스케이스 흐름과 트랜잭션 경계만 책임진다.

java
// application/service/PlaceOrderService.java
@Service
@RequiredArgsConstructor
public class PlaceOrderService implements PlaceOrderUseCase {
 
    private final OrderRepository orderRepository;     // port.out
    private final PaymentPort paymentPort;             // port.out
    private final StoreInventoryPort inventoryPort;    // port.out
    private final OrderEventPublisher eventPublisher;  // port.out
    private final CouponPolicyFactory couponFactory;
 
    @Override
    @Transactional
    public OrderId place(PlaceOrderCommand cmd) {
        inventoryPort.reserve(cmd.storeId(), cmd.lineItems());
 
        var coupon = couponFactory.of(cmd.couponCode());
        var order  = Order.place(cmd.storeId(), cmd.toLines(), coupon);
        var saved  = orderRepository.save(order);
 
        var paid = paymentPort.pay(saved.id(), saved.totalAmount(), cmd.cardToken());
        if (!paid.isSuccess()) {
            throw new PaymentFailedException(paid.reason());
        }
        saved.markPaid();
        orderRepository.save(saved);
 
        eventPublisher.publishCreated(saved);
        return saved.id();
    }
}

어댑터는 외부 기술과만 대화한다.

java
// adapter.out.payment/TossPaymentAdapter.java
@Component
@RequiredArgsConstructor
class TossPaymentAdapter implements PaymentPort {
    private final TossClient tossClient;
 
    @Override
    public PaymentResult pay(OrderId orderId, Money amount, String cardToken) {
        var res = tossClient.charge(orderId.value(), amount.toLong(), cardToken);
        return res.isApproved()
            ? PaymentResult.success(res.transactionId())
            : PaymentResult.fail(res.reasonCode());
    }
}

이 구조의 효과는 다음과 같다.

  • 가격 계산은 Order.place만 단위 테스트하면 된다. Spring 컨텍스트가 필요 없다.
  • PG가 토스에서 NICE로 바뀌어도 NicePaymentAdapter 추가, 빈 등록만 바꾼다.
  • "결제 후 주문 갱신 실패" 시나리오는 PlaceOrderService 통합 테스트에서 어댑터를 가짜 구현으로 바꿔 검증한다.
  • 트랜잭션 경계가 application service에 명확히 한 점만 있다.

트랜잭션 스크립트 vs 도메인 모델: 언제 무엇을 쓰는가

마틴 파울러의 분류대로, 단순 매장 영업시간 같은 영역에 도메인 모델을 강제하면 오히려 코드가 늘어난다. 다음 신호가 보이면 도메인 모델로 옮긴다.

  • 같은 if-else가 3개 이상 서비스 메서드에 반복된다.
  • 상태 전이가 4개 이상이고, 잘못된 전이를 막아야 한다(주문, 정산, 환불).
  • 가격/할인/적립 등 정책이 자주 바뀐다.
  • 동일 데이터에 대해 "검증"과 "변경"이 같이 일어난다.

반대로 다음이면 그대로 둔다.

  • 화면 한 개에서만 쓰는 단순 조회/저장.
  • 외부 시스템 응답을 그대로 저장만 하는 ETL성 코드.
  • 운영자 화면처럼 트래픽이 낮고 정책이 거의 없는 영역.

테스트 경계 잡는 법

헥사고날의 가장 큰 보상은 테스트 피라미드를 짤 자리가 생기는 것이다.

테스트 종류대상도구비고
단위Order, Money, CouponPolicyJUnit만Spring 없음, 가장 많이 짠다
applicationPlaceOrderServiceJUnit + Fake/Stub 어댑터포트의 fake 구현으로 빠르게
어댑터OrderPersistenceAdapter, TossPaymentAdapter@DataJpaTest, WireMock외부 기술별로 분리
인수HTTP → DB@SpringBootTest + Testcontainers핵심 시나리오 소수

여기서 자주 빠지는 함정은 application service 테스트에 @SpringBootTest를 쓰는 것이다. 그러면 빌드가 느려지고, 테스트가 어댑터의 실수까지 같이 잡으려다 의도가 흐려진다. application 테스트에서는 포트 인터페이스의 in-memory 가짜 구현을 직접 만든다.

java
class FakeOrderRepository implements OrderRepository {
    private final Map<Long, Order> store = new HashMap<>();
    private final AtomicLong seq = new AtomicLong();
    public Order save(Order order) { /* id 발급 후 저장 */ }
    public Optional<Order> findById(OrderId id) { /* */ }
}

자주 나오는 잘못된 적용

  • 포트가 JPA Repository와 1:1 메서드 매핑: findByStoreIdAndStatus 같은 JPA 시그니처가 그대로 port에 노출되면 도메인이 SQL 모양을 알게 된다. 포트는 도메인 언어로(findActiveOrdersOf(StoreId)) 정의한다.
  • 도메인이 @Entity와 같은 클래스: 처음에는 편하지만 곧 @OneToMany lazy 로딩, dirty checking이 도메인 메서드에 영향을 준다. 도메인 POJO와 JPA 엔티티는 분리하고, 어댑터에서 매핑 책임을 진다(MapStruct 또는 손코딩).
  • 모든 곳에 UseCase 인터페이스: 단일 구현뿐인 인터페이스를 무조건 만들면 오히려 노이즈다. 외부에서 "정책 교체 가능성"이 실제로 있는 포트만 인터페이스로 둔다(in-port는 자주 단일 구현이라 생략 가능).
  • DTO를 도메인 객체 대신 곳곳에 흘림: Controller가 받은 Request가 그대로 application, domain까지 흘러들어가면 외부 표현이 도메인을 오염시킨다. application 입구에서 Command로 변환한다.
  • 트랜잭션을 어댑터에 거는 경우: @Transactional은 application service에만 둔다. 어댑터에 걸면 여러 어댑터가 호출될 때 트랜잭션 경계가 흐려진다.

로컬 실습 환경

다음 조건을 그대로 따라 하면 1~2시간 안에 헥사고날 미니 커머스를 띄울 수 있다.

  • Java 17, Spring Boot 3.x
  • MySQL 8 (Docker)
  • WireMock(가짜 PG)
  • Testcontainers(통합 테스트)
bash
docker run --name commerce-mysql \
  -e MYSQL_ROOT_PASSWORD=root \
  -e MYSQL_DATABASE=commerce \
  -p 3306:3306 -d mysql:8.0
 
docker run --name fake-pg \
  -p 8089:8080 -d wiremock/wiremock:3.5.4

build.gradle.kts 핵심 의존성.

kotlin
dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("org.springframework.boot:spring-boot-starter-data-jpa")
    runtimeOnly("com.mysql:mysql-connector-j")
 
    testImplementation("org.springframework.boot:spring-boot-starter-test")
    testImplementation("com.tngtech.archunit:archunit-junit5:1.3.0")
    testImplementation("org.testcontainers:mysql:1.20.1")
    testImplementation("org.wiremock:wiremock-standalone:3.5.4")
}

실습 과제: 한 시간짜리 미니 주문 서비스

  1. domain.Order, OrderLine, Money, OrderStatus를 POJO로 작성. Money는 BigDecimal + Currency.
  2. PlaceOrderUseCase(in-port), OrderRepository/PaymentPort(out-port) 정의.
  3. PlaceOrderService 구현. @Transactional 한 메서드만.
  4. JPA 어댑터: OrderJpaEntity, OrderJpaRepository, OrderPersistenceAdapter. 도메인 ↔ 엔티티 매핑은 어댑터 안에서.
  5. WireMock으로 PG 모킹: 200 OK + {"result":"OK"}. TossPaymentAdapter가 이걸 호출.
  6. 인수 테스트: 1) 정상 결제, 2) PG 실패 시 주문 PENDING 유지, 3) 빈 주문 시 400.
  7. ArchUnit 테스트로 domain → spring/jpa/adapter 의존 금지 강제.
  8. 가격 정책에 "쿠폰 10%"를 넣고, 그 정책만 단위 테스트로 분리해 본다. Spring을 띄우지 않는다.

이 과제를 끝까지 마쳤다면, 기존 본인 프로젝트(task/ 기록이 있는 영역) 중 한 군데를 골라 같은 구조로 1주일 안에 리팩터링해 본다. 변경 전후 테스트 수행 시간, 변경된 파일 수를 기록해 두면 면접에서 매우 강력한 근거가 된다.

면접 답변 프레이밍 (시니어 백엔드)

Q. 모든 프로젝트에 클린 아키텍처를 적용하시나요?

A. 아닙니다. 도메인의 복잡도와 외부 통합 수에 따라 다르게 적용합니다. CRUD에 가까운 운영자 화면은 트랜잭션 스크립트와 JPA Repository 직결로 충분하고, 주문·결제·정산처럼 상태 머신과 외부 통합이 많은 영역에만 포트/어댑�터를 강제합니다. 같은 코드베이스 안에서 두 스타일이 공존하는 것이 현실적이라고 봅니다.

Q. 그렇게 하면 신입이 헷갈리지 않나요?

A. 그래서 두 가지 장치를 둡니다. 첫째, 도메인 패키지 안에서 Spring/JPA 의존성을 ArchUnit으로 막아 어디까지가 "정책"인지 컴파일 타임에 보이게 합니다. 둘째, 포트/어댑터를 적용하는 영역의 기준을 README에 적어 둡니다. 외부 시스템과 직접 대화하는 영역, 상태 전이가 4개 이상인 영역, 정책이 자주 바뀌는 영역, 이 세 가지 중 두 가지가 겹치면 헥사고날로 갑니다.

Q. 도메인 객체와 JPA 엔티티를 분리하면 매핑 코드가 많이 늘지 않나요?

A. 늘어납니다. 다만 매핑 코드가 늘어나는 비용보다, JPA의 lazy 로딩이나 dirty checking이 도메인 메서드 동작을 바꾸는 사고가 더 큽니다. 매핑은 MapStruct로 거의 자동화 가능하고, 매핑 한 군데가 바뀐다고 해서 다른 도메인 메서드가 깨지지 않는다는 점이 장기적으로 더 큰 가치라고 판단합니다. 단순 CRUD 영역에서는 굳이 분리하지 않습니다.

Q. 트랜잭션 경계는 어떻게 잡으세요?

A. application service의 유스케이스 메서드 한 점에만 @Transactional을 둡니다. 어댑터에는 걸지 않습니다. 외부 호출(PG, 메시지 발행)이 트랜잭션 안에 들어가면 commit 시점과 외부 효과 시점이 어긋나 정합성이 깨질 수 있어, 가능하면 외부 호출은 트랜잭션 밖이나 outbox 패턴으로 분리합니다.

Q. 헥사고날을 도입하면서 가장 크게 얻은 것은요?

A. 단위 테스트의 비중이 늘었다는 점입니다. 도메인 단위 테스트가 전체 테스트의 70%를 차지하면서 빌드 시간이 줄고, 정책 변경 PR에서 깨지는 테스트가 곧바로 정책 회귀를 가리키게 됐습니다. 반대로 가장 신경 쓴 부분은 "어디까지 적용할지"였고, 이걸 팀 합의로 문서화하지 않으면 같은 코드베이스가 두 스타일로 깨져서 더 나빠질 수 있다는 걸 경험했습니다.

체크리스트

  • 도메인 패키지에 Spring/JPA 의존이 없는가 (ArchUnit으로 강제)
  • @Transactional은 application service에만 있는가
  • 포트 메서드가 도메인 언어로 정의되었는가 (JPA 시그니처 노출 금지)
  • 도메인 객체와 JPA 엔티티가 핵심 도메인에서 분리되어 있는가
  • application service 테스트가 @SpringBootTest 없이 fake 어댑터로 돌아가는가
  • 외부 호출(PG, 메시지)은 트랜잭션 밖이거나 outbox로 분리되어 있는가
  • CRUD 영역에까지 헥사고날을 강제하고 있지 않은가
  • 어댑터별 통합 테스트가 분리되어 있는가 (@DataJpaTest, WireMock 등)
  • Controller가 받은 Request를 application 입구에서 Command로 변환하는가
  • 도메인 메서드에 상태 전이 검증이 있고, 잘못된 전이가 예외로 막히는가
on this page
  • 01왜 중요한가
  • 02핵심 개념: 의존성 방향만 기억하면 된다
  • 03커머스에서 어디까지 적용할지: CRUD vs 복잡 도메인
  • 04패키지·모듈 구조 한 가지 안
  • 05나쁜 예: 트랜잭션 스크립트로 뒤엉킨 주문 서비스
  • 06개선 예: 포트/어댑터 + 도메인 모델
  • 07트랜잭션 스크립트 vs 도메인 모델: 언제 무엇을 쓰는가
  • 08테스트 경계 잡는 법
  • 09자주 나오는 잘못된 적용
  • 10로컬 실습 환경
  • 11실습 과제: 한 시간짜리 미니 주문 서비스
  • 12면접 답변 프레이밍 (시니어 백엔드)
  • 13체크리스트

댓글 (0)