백엔드 아키텍처 선택 가이드

flowchart TB
    subgraph S[시스템 수준: 어떻게 나눌까]
        DDDS[DDD 전략 설계<br/>Bounded Context]
    end

    subgraph M[모듈 내부: 어떻게 짤까]
        ARCH[Layered / Hexagonal /<br/>Onion / Clean]
        DDDT[DDD 전술 설계<br/>Entity · VO · Aggregate]
        CQRS[CQRS]
        ES[Event Sourcing]
    end

    subgraph C[모듈 사이: 어떻게 연결할까]
        EDA[Event-Driven Architecture]
        OB[Transactional Outbox]
        SAGA[Saga]
    end

    DDDS -->|각 Context마다 선택| ARCH
    ARCH -->|안쪽 도메인을 표현| DDDT
    DDDT -->|복잡한 조회를 분리| CQRS
    ES -->|조회를 위해 거의 필수| CQRS
    DDDS -->|Context 사이 연결| EDA
    EDA -->|발행 신뢰성| OB
    EDA -->|분산 흐름과 보상| SAGA
    SAGA -->|명령·상태 발행| OB
    CQRS -->|읽기 모델 동기화| EDA

flowchart TD
    A[새 모듈 / Bounded Context] --> B{업무 규칙이 복잡한가?<br/>상태 전이, 계산, 정책이 많은가?}
    B -- 아니오 --> L[Layered]
    B -- 예 --> C{외부 시스템 연동이 많거나<br/>DB·프레임워크 교체 가능성이 있나?}
    C -- 아니오 --> L2[Layered +<br/>Repository 인터페이스 분리<br/>+ 규칙은 도메인 객체로]
    C -- 예 --> D{DDD로 깊게 모델링하나?}
    D -- 예 --> O[Onion 또는<br/>Hexagonal + DDD 전술 설계]
    D -- 아니오 --> E{유스케이스를 명시적으로 드러내고<br/>출력 형식이 다양한가?}
    E -- 예 --> CL[Clean]
    E -- 아니오 --> H[Hexagonal]

flowchart TD
    A[조회가 느리거나 복잡하다] --> B{Aggregate/Repository를<br/>거쳐서 조회하고 있나?}
    B -- 예 --> C1[CQRS 1단계<br/>Query 핸들러에서 SQL 직접]
    B -- 아니오 --> C{JOIN이 너무 많아<br/>쿼리 자체가 느린가?}
    C1 --> C
    C -- 아니오 --> I[인덱스·쿼리 튜닝]
    C -- 예 --> D[CQRS 2단계<br/>읽기 전용 테이블]
    D --> E{검색엔진·캐시 같은 전용 저장소가 필요하거나<br/>다른 서비스 데이터를 모아야 하나?}
    E -- 아니오 --> STOP[2단계 유지]
    E -- 예 --> F{결과적 일관성 허용?}
    F -- 아니오 --> STOP
    F -- 예 --> G[CQRS 3단계<br/>+ EDA + Outbox]

flowchart TD
    A[A 작업 후 다른 모듈의 B 작업이 필요하다] --> B{B의 결과가<br/>A의 응답에 필요한가?}
    B -- 예 --> SYNC[동기 호출<br/>REST / gRPC / 같은 프로세스 호출]
    B -- 아니오 --> C{같은 프로세스·같은 DB인가?}
    C -- 예 --> D{B가 실패하면<br/>A도 되돌려야 하나?}
    D -- 예 --> TX[같은 DB 트랜잭션<br/>또는 경계 재검토]
    D -- 아니오 --> MEM[메모리 이벤트<br/>@nestjs/event-emitter]
    C -- 아니오, 서비스가 다르다 --> E[브로커 이벤트<br/>EDA]
    E --> F[Transactional Outbox로 발행]
    F --> G{B 실패 시<br/>A를 되돌려야 하나?}
    G -- 아니오 --> DONE[멱등 소비자로 마무리]
    G -- 예 --> SAGA[Saga<br/>단계 ≤3: Choreography<br/>단계 >3: Orchestration]

flowchart TD
    A[변경 이력이 필요하다] --> B{"누가 언제 바꿨나"<br/>정도면 충분한가?}
    B -- 예 --> AUDIT[감사 로그 테이블<br/>또는 DB 트리거]
    B -- 아니오 --> C{과거 시점 상태 재현이나<br/>소급 분석이 업무 핵심인가?}
    C -- 아니오 --> AUDIT
    C -- 예 --> ES[Event Sourcing<br/>+ CQRS<br/>해당 Aggregate에만]

1단계: MVP / 초기
  - Layered
  - 모놀리스, DB 하나
  - 폴더는 업무 기준으로 (order/, payment/ ...)
        │  규칙이 늘고, 테스트가 무거워지고, 서비스가 비대해진다
        ▼
2단계: 성장기
  - 모듈 경계 정리 (DDD 전략 설계, 모듈러 모놀리스)
  - Core 모듈만 Hexagonal/Onion + 도메인 객체에 규칙 이동
  - 조회는 CQRS 1단계 (Query 핸들러 분리)
  - 후속 작업은 메모리 이벤트로 분리
        │  팀이 늘고, 배포가 충돌하고, 특정 모듈만 트래픽이 크다
        ▼
3단계: 확장기
  - 일부 Context를 서비스로 분리
  - 서비스 간 연결은 EDA (Kafka 등) + Transactional Outbox
  - 서비스에 걸친 흐름은 Saga
  - 대량 조회는 CQRS 2~3단계
        │  감사, 규제, 이력 분석이 업무 핵심인 영역이 있다
        ▼
4단계: 특수 요구
  - 해당 Aggregate에만 Event Sourcing

구조:   Layered, 모놀리스, PostgreSQL 하나
이벤트: 없음 또는 메모리 이벤트 (주문 후 메일 발송)
조회:   ORM으로 직접

src/
├── ordering/    Hexagonal + DDD 전술 + CQRS 1단계     (Core)
├── payment/     Hexagonal (외부 PG 어댑터 + ACL)
├── catalog/     Layered + CQRS 2단계 (상품 목록 읽기 테이블)
├── admin/       Layered
└── notification/ Layered (메모리 이벤트 구독)

연결: @nestjs/event-emitter + Outbox 테이블 (서비스 분리 대비)

주문 서비스    Onion/Clean + DDD + CQRS + Outbox + 주문 Saga 오케스트레이터
재고 서비스    Hexagonal + Saga 참여자 (멱등한 예약/해제)
결제 서비스    Hexagonal + ACL (PG 연동) + Saga 참여자
배송 서비스    Hexagonal + EDA 구독
검색 서비스    CQRS 읽기 전용 (Elasticsearch, 이벤트로 동기화)
알림 서비스    Layered + EDA 구독

연결: Kafka + Outbox(Debezium) + 멱등 소비자 + DLQ + 분산 추적

계좌/원장      Event Sourcing + CQRS (모든 거래 이력이 원본)
송금           Saga (출금 계좌 → 입금 계좌, 실패 시 보상)
고객 정보      Layered (개인정보는 이벤트 밖에 저장)
리포트         CQRS 읽기 모델 (Projection으로 일별 잔액, 거래 통계)