[volume - 8] Decoupling with Kafka #196

rnqhstmd · 2025-12-19T06:35:27Z

📌 Summary

Kafka 연동
kafka 모듈, commerce-streamer 앱 연동
Partition 확장 및 메시지 발행 시 retry, fallback 처리 적용
감사 로그, 집계 이벤트 Kafka 전송
이벤트 처리 안정성
event handled 테이블 기반 멱등 처리
DLQ 처리
재시도 후 실패한 메세지 DLT 토픽 전송 및 저장

💬 Review Points

멱등처리를 위한 event_handled 테이블과 로그 테이블 분리는 서로 다른 책임을 가지고 있다고 생각했습니다. event_handled 테이블은 이벤트 중복 처리 방지만 담당하고, 로그 테이블은 상세 유저 행동 데이터를 꾸준히 저장하는 역할을 담당한다고 판단하여 만약 하나의 테이블로 통합하면 불필요한 칼럼 증가, 데이터 관리 어려움 등의 불편한점이 있을 것 같습니다.

✅ Checklist

🎾 Producer

도메인(애플리케이션) 이벤트 설계
Producer 앱에서 도메인 이벤트 발행 (catalog-events, order-events, 등)
PartitionKey 기반의 이벤트 순서 보장
메세지 발행이 실패했을 경우에 대해 고민해보기

⚾ Consumer

Consumer 가 Metrics 집계 처리
event_handled 테이블을 통한 멱등 처리 구현
재고 소진 시 상품 캐시 갱신
중복 메세지 재전송 테스트 → 최종 결과가 한 번만 반영되는지 확인

Summary by CodeRabbit

릴리스 노트

새 기능
- 상품 조회, 좋아요, 재고 변동 등의 이벤트 추적 및 메트릭 수집 기능 추가
- 감사 로그를 통한 사용자 활동 기록 개선
- 실패한 작업 자동 재시도 메커니즘 강화
버그 수정
- 쿠폰 중복 사용 방지 로직 추가

_{✏️ Tip: You can customize this high-level summary in your review settings.}

…ryImpl 클래스 추가 및 저장 메서드 구현

…positoryImpl 클래스 추가 및 DLQ 메시지 처리 메서드 구현

…dledRepositoryImpl 클래스 추가 및 이벤트 처리 메서드 구현

coderabbitai · 2025-12-19T06:35:39Z

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

요약

이 PR은 Kafka 기반 이벤트 주도 아키텍처를 도입하여 주문, 결제, 상품 이벤트를 비동기로 처리합니다. Outbox 패턴을 적용하고 새로운 commerce-streamer 애플리케이션을 추가하여 메트릭, 감사 로그, DLQ 처리를 구현합니다.

Walkthrough

commerce-api와 새로운 commerce-streamer 애플리케이션에 Kafka 기반 이벤트 시스템을 도입합니다. Outbox 패턴으로 이벤트 지속성을 보장하고, 여러 Kafka 프로듀서로 주문·결제·상품 이벤트를 발행하며, 스트리머 애플리케이션에서 메트릭, 감사 로그, DLQ를 처리합니다.

Changes

변경 대상 / 파일(들)	요약
Kafka 의존성 및 설정 `apps/commerce-api/build.gradle.kts`, `apps/commerce-api/src/main/resources/application.yml`, `modules/kafka/src/main/resources/kafka.yml`, `modules/kafka/src/main/java/com/loopers/confg/kafka/KafkaConfig.java`	Kafka 모듈 및 테스트 의존성 추가. DLQ 처리, 에러 핸들링, 멱등성 및 acks 설정 구성 추가.
Outbox 이벤트 인프라 `apps/commerce-api/src/main/java/com/loopers/domain/outbox/OutboxEvent.java`, `OutboxEventRepository.java`, `OutboxService.java`, `apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventJpaRepository.java`, `OutboxEventRepositoryImpl.java`, `OutboxEventPublisher.java`	Outbox 엔티티, 리포지토리, 서비스, JPA 구현 및 예약된 발행자 추가. PENDING/PROCESSED/FAILED 상태 관리.
이벤트 DTO 및 프로듀서 `apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/Dto.java`, `apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/Producer.java`	OrderEventDto, PaymentEventDto, LikeChangedDto, StockChangedDto, ProductViewedDto, UserActionDto 레코드 추가. 각 이벤트 타입별 Kafka 프로듀서 컴포넌트 추가 (재시도 정책 포함).
이벤트 리스너 `apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/OrderEventListener.java`, `PaymentEventListener.java`, `ProductLikeEventListener.java`, `UserActionEventListener.java`	주문 생성, 결제 성공/실패, 상품 좋아요 이벤트에 Outbox 및 Kafka 발행 핸들러 추가.
도메인 로직 수정 `apps/commerce-api/src/main/java/com/loopers/application/order/OrderFacade.java`, `apps/commerce-api/src/main/java/com/loopers/domain/payment/event/PaymentSucceededEvent.java`	useCoupon에 멱등성 가드 추가. PaymentSucceededEvent에 transactionId 필드 추가.
commerce-streamer 애플리케이션 - 도메인 `apps/commerce-streamer/src/main/java/com/loopers/domain/auditlog/`, `apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/`, `apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/`, `apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/`	AuditLog, DlqMessage, EventHandled, ProductMetrics 엔티티 및 리포지토리 추가.
commerce-streamer 애플리케이션 - 애플리케이션 계층 `apps/commerce-streamer/src/main/java/com/loopers/application/auditlog/AuditLogFacade.java`, `AuditLogCommand.java`, `apps/commerce-streamer/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java`, `ProductMetricsCommand.java`, `MetricsType.java`	감사 로그 및 메트릭 처리 파사드, 커맨드 객체, 메트릭 타입 열거형 추가.
commerce-streamer 애플리케이션 - 인프라 및 컨슈머 `apps/commerce-streamer/src/main/java/com/loopers/infrastructure/auditlog/`, `apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/`, `apps/commerce-streamer/src/main/java/com/loopers/infrastructure/eventhandled/`, `apps/commerce-streamer/src/main/java/com/loopers/infrastructure/metrics/`, `apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/*`	JPA 리포지토리 구현체, Kafka 컨슈머(AuditLogConsumer, DlqConsumer, ProductMetricsConsumer) 추가. DemoKafkaConsumer 제거.
commerce-streamer 애플리케이션 - DTO 및 설정 `apps/commerce-streamer/src/main/java/com/loopers/interfaces/dto/*`, `apps/commerce-streamer/src/main/resources/application.yml`, `apps/commerce-streamer/src/main/java/com/loopers/support/config/TimeConfig.java`	ProductLikePayload, ProductStockPayload, ProductViewPayload 레코드 추가. Kafka 토픽 및 컨슈머 그룹 설정. Clock 빈 추가.
테스트 `apps/commerce-streamer/src/test/java/com/loopers/*`	CommerceStreamerContextTest, AuditLogConsumerTest, DlqConsumerTest, ProductMetricsConsumerTest 추가.

Sequence Diagram(s)

sequenceDiagram
    actor User
    participant OrderAPI as Order API
    participant OrderListener as OrderEventListener
    participant OutboxService as OutboxService
    participant OutboxPublisher as OutboxEventPublisher
    participant Kafka as Kafka
    participant StockProducer as StockChangedEventProducer

    User->>OrderAPI: POST /orders
    activate OrderAPI
    OrderAPI->>OrderAPI: Create Order
    OrderAPI->>OrderListener: Order Created Event
    deactivate OrderAPI

    activate OrderListener
    OrderListener->>OutboxService: Save Outbox Event
    activate OutboxService
    OutboxService->>OutboxService: Serialize Payload
    OutboxService->>OrderListener: Event Saved
    deactivate OutboxService

    OrderListener->>StockProducer: Send Stock Changed Events
    activate StockProducer
    StockProducer->>Kafka: Publish (with retry)
    Kafka-->>StockProducer: Ack/Nack
    deactivate StockProducer
    deactivate OrderListener

    activate OutboxPublisher
    OutboxPublisher->>OutboxPublisher: Poll Pending Events (every 1s)
    OutboxPublisher->>Kafka: Send to Topic
    Kafka-->>OutboxPublisher: Success/Failure
    OutboxPublisher->>OutboxPublisher: Mark as PROCESSED/FAILED
    deactivate OutboxPublisher

sequenceDiagram
    participant Kafka as Kafka Topics
    participant Consumer as ProductMetricsConsumer
    participant Facade as ProductMetricsFacade
    participant MetricsService as ProductMetricsService
    participant Repository as ProductMetricsRepository
    participant Cache as Redis Cache

    Kafka->>Consumer: Batch Messages (like/stock/view)
    activate Consumer
    
    loop For Each Record
        Consumer->>Facade: processLikeMetrics/Stock/View
        activate Facade
        Facade->>MetricsService: Process Metrics
        activate MetricsService
        MetricsService->>Repository: Get or Create ProductMetrics
        Repository-->>MetricsService: ProductMetrics
        MetricsService->>MetricsService: Update Delta (likes/sales/views)
        MetricsService->>Repository: Save
        Repository-->>MetricsService: Saved
        deactivate MetricsService
        
        alt Stock Metrics
            Facade->>Cache: Invalidate Product Caches
            Cache-->>Facade: Done
        end
        Facade-->>Consumer: Complete
        deactivate Facade
    end
    
    Consumer->>Kafka: Acknowledge Batch
    deactivate Consumer

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120+ 분

추가 검토 필요 사항:

아웃박스 패턴 구현: OutboxEventPublisher의 예약된 작업 로직과 트랜잭션 경계 확인 필요 (OutboxEventPublisher.java)
Kafka 프로듀서 재시도 정책: 모든 프로듀서의 @Retry 어노테이션 설정 및 폴백 메서드 일관성 검증 (*Producer.java 파일들)
컨슈머 에러 핸들링: DLQ 라우팅, 배치 처리 중 개별 레코드 실패 처리, 멱등성 보장 검증 (*Consumer.java, KafkaConfig.java)
새 애플리케이션 통합: commerce-streamer의 도메인 엔티티, 서비스 계층, 리포지토리 구현 전반적 검토
멀티 모듈 의존성: gradle 의존성 추가 및 모듈 간 순환 의존성 없음 확인 (build.gradle.kts)
데이터 일관성: Outbox 상태 전환, 메트릭 계산 로직, 감사 로그 레코드 정확성
구성 관리: 토픽 이름, 컨슈머 그룹, 타임아웃 설정의 환경별 일관성

Possibly related PRs

[volume-5] 인덱스 및 Redis 캐시 적용 #143: OrderFacade.java 동일 파일 수정 — 캐시 무효화와 쿠폰 멱등성 로직이 겹치는 영역
[volume-7] Decoupling with Event #189: Kafka/Outbox 이벤트 흐름, 결제/주문 프로듀서 및 리스너 클래스와 직접적인 코드 중복
[volume-7] Decoupling with Event #172: Outbox 엔티티/서비스/리포지토리 및 Kafka 이벤트 프로듀서 구현 중복

Poem

🐰 토끼의 축하 시

이벤트의 홀을 장식하니,
아웃박스는 약속을 지키고,
스트리머가 메트릭을 노래하네.
Kafka의 흐름 속에서,
멱등성 있는 춤을 춘다! 🎉

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 10.83% which is insufficient. The required threshold is 80.00%.	You can run `@coderabbitai generate docstrings` to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	제목 '[volume - 8] Decoupling with Kafka'는 PR의 주요 변경사항인 Kafka 연동 및 이벤트 기반 아키텍처로의 전환을 명확하게 나타냅니다.
Description check	✅ Passed	PR 설명은 요구되는 템플릿의 주요 섹션(Summary, Review Points, Checklist)을 포함하고 있으며 충실한 내용을 담고 있습니다.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

Actionable comments posted: 18

Note

Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/commerce-streamer/src/main/resources/application.yml (1)
16-17: 애플리케이션 이름이 잘못 설정됨

이 파일은 commerce-streamer 애플리케이션용이지만 spring.application.name이 commerce-api로 설정되어 있습니다. 이로 인해 모니터링, 로깅, Kafka consumer group 식별에 혼란이 발생할 수 있습니다.
🔎 수정 제안
 spring:
   application:
-    name: commerce-api
+    name: commerce-streamer

🟡 Minor comments (4)

apps/commerce-streamer/src/main/resources/application.yml-27-27 (1)
27-27: YAML 구문 오류: 빈 리스트 항목

Line 27의 단독 -는 빈 리스트 항목을 생성합니다. 의도치 않은 구문이라면 제거가 필요합니다.
🔎 수정 제안
       - kafka.yml
       - logging.yml
       - monitoring.yml
-      -
 kafka:
apps/commerce-streamer/src/test/java/com/loopers/interfaces/AuditLogConsumerTest.java-32-84 (1)
32-84: acknowledge() 호출 검증 추가 필요

Happy path와 edge case(blank userId) 모두 잘 테스트하고 있습니다. 다만 AuditLogConsumer 구현에서 finally 블록(line 54)에서 항상 acknowledgment.acknowledge()를 호출하므로, 테스트에서도 이를 검증해야 합니다. 두 테스트 메서드 모두에 다음과 같은 검증을 추가하세요:
verify(acknowledgment, times(1)).acknowledge();
apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventJpaRepository.java-12-16 (1)
12-16: JPQL LIMIT 절 사용 권장사항 검토

현재 코드가 Hibernate 6.6+에서 지원하는 LIMIT 절을 사용 중이므로 런타임 오류는 발생하지 않습니다. 그러나 LIMIT은 표준 JPQL 스펙의 일부가 아니므로, 호환성과 가독성을 위해 Pageable을 사용하는 것을 권장합니다:
-@Query("SELECT o FROM OutboxEvent o WHERE o.status = 'PENDING' ORDER BY o.createdAt ASC LIMIT :limit")
-List<OutboxEvent> findPendingEvents(@Param("limit") int limit);
+@Query("SELECT o FROM OutboxEvent o WHERE o.status = 'PENDING' ORDER BY o.createdAt ASC")
+List<OutboxEvent> findPendingEvents(Pageable pageable);

-@Query("SELECT o FROM OutboxEvent o WHERE o.status = 'FAILED' AND o.retryCount < :maxRetryCount ORDER BY o.createdAt ASC LIMIT :limit")
-List<OutboxEvent> findFailedEventsForRetry(@Param("maxRetryCount") int maxRetryCount, @Param("limit") int limit);
+@Query("SELECT o FROM OutboxEvent o WHERE o.status = 'FAILED' AND o.retryCount < :maxRetryCount ORDER BY o.createdAt ASC")
+List<OutboxEvent> findFailedEventsForRetry(@Param("maxRetryCount") int maxRetryCount, Pageable pageable);
호출 시: PageRequest.of(0, limit)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/OrderEventProducer.java-31-34 (1)
31-34: 비동기 전송 완료 전 성공 로그 출력

kafkaTemplate.send()는 비동기 메서드로 CompletableFuture를 반환합니다. 현재 코드는 실제 전송 완료 여부와 관계없이 즉시 성공 로그를 출력하고 있어, 실제로 실패한 경우에도 성공 로그가 남을 수 있습니다.
🔎 콜백을 통한 정확한 로깅 제안
-    kafkaTemplate.send(orderEventsTopic, orderId.toString(), event);
-    log.info("주문 생성 이벤트 발행: orderId={}, userId={}", orderId, userId);
+    kafkaTemplate.send(orderEventsTopic, orderId.toString(), event)
+        .whenComplete((result, ex) -> {
+            if (ex == null) {
+                log.info("주문 생성 이벤트 발행 완료: orderId={}, userId={}", orderId, userId);
+            } else {
+                log.error("주문 생성 이벤트 발행 실패: orderId={}, userId={}", orderId, userId, ex);
+            }
+        });
다른 send 메서드들(sendOrderCompletedEvent, sendOrderFailedEvent)에도 동일하게 적용이 필요합니다.

🧹 Nitpick comments (37)

modules/kafka/src/main/java/com/loopers/confg/kafka/KafkaConfig.java (1)
77-85: Non-retryable 예외 추가 고려

IllegalArgumentException 외에도 재시도해도 해결되지 않는 예외들을 추가하는 것이 좋습니다. 예: NullPointerException, ClassCastException, deserialization 관련 예외 등.
🔎 권장 수정안
     @Bean
     public CommonErrorHandler errorHandler(DeadLetterPublishingRecoverer recoverer) {
         DefaultErrorHandler errorHandler = new DefaultErrorHandler(
                 recoverer,
                 new FixedBackOff(DLQ_RETRY_INTERVAL, DLQ_MAX_ATTEMPTS)
         );
-        errorHandler.addNotRetryableExceptions(IllegalArgumentException.class);
+        errorHandler.addNotRetryableExceptions(
+                IllegalArgumentException.class,
+                NullPointerException.class,
+                ClassCastException.class
+        );
         return errorHandler;
     }
apps/commerce-streamer/src/main/java/com/loopers/application/auditlog/AuditLogCommand.java (1)

22-24: eventType()과 actionType 명명 혼란

eventType() 메서드가 actionType을 반환하는 것은 명명 불일치를 유발합니다. record의 기본 접근자인 actionType()을 사용하거나, 필드명 자체를 eventType으로 통일하는 것이 가독성에 좋습니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/auditlog/AuditLog.java (1)

56-56: 테스트 용이성을 위한 Clock 주입 고려

LocalDateTime.now()를 직접 호출하면 단위 테스트에서 시간 관련 검증이 어려울 수 있습니다. 테스트 용이성이 중요한 경우 Clock 파라미터를 받도록 리팩토링을 고려해 볼 수 있습니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/LikeChangedDto.java (1)

8-8: likeType에 enum 사용 고려

likeType이 String으로 정의되어 있습니다. 타입 안전성과 유효성 검증을 강화하려면 enum 타입(예: LikeType.LIKE, LikeType.UNLIKE)을 사용하는 것을 고려해 볼 수 있습니다.
apps/commerce-api/src/main/java/com/loopers/domain/outbox/OutboxEvent.java (1)
51-52: lastError 컬럼에 길이 제한 고려 필요

스택 트레이스나 긴 에러 메시지가 저장될 경우, 컬럼 길이 제한이 없으면 DB에 따라 예기치 않은 잘림이나 오류가 발생할 수 있습니다.
🔎 길이 제한 또는 TEXT 타입 명시 제안
-    @Column(name = "last_error")
+    @Column(name = "last_error", columnDefinition = "TEXT")
     private String lastError;
apps/commerce-streamer/src/main/java/com/loopers/support/config/TimeConfig.java (1)

8-15: 테스트 용이성을 위한 Clock 빈 설정 - 좋은 접근입니다.

Clock을 빈으로 주입받을 수 있게 하여 테스트에서 시간을 제어할 수 있습니다.

분산 시스템에서 타임존 일관성이 중요한 경우, Clock.system(ZoneId.of("Asia/Seoul")) 또는 UTC 기반 Clock 사용을 고려할 수 있습니다. 현재 systemDefaultZone()은 서버 로케일에 따라 달라질 수 있습니다.

apps/commerce-streamer/src/main/java/com/loopers/interfaces/dto/ProductStockPayload.java (1)

3-9: LGTM!

Kafka 메시지 페이로드로 적합한 불변 레코드입니다. eventId가 String 타입으로 OutboxEvent의 UUID 기반 ID와 일관성이 있습니다.

changedType이 고정된 값 집합(예: INCREASE, DECREASE)이라면, 타입 안전성을 위해 enum 사용을 고려할 수 있습니다. 다만 Kafka 역직렬화 시 유연성이 필요하다면 현재 String 타입도 적절합니다.
apps/commerce-api/src/main/resources/application.yml (1)
38-44: Kafka Producer 재시도 설정에 지수 백오프 추가를 고려해보세요.

현재 kafkaProducer 설정은 고정 대기 시간(wait-duration: 1s)을 사용하고 있습니다. 아래 pgRetry 설정처럼 지수 백오프를 적용하면 일시적인 브로커 과부하 상황에서 더 효과적으로 복구할 수 있습니다.
🔎 지수 백오프 설정 예시
 kafkaProducer:
   max-attempts: 3
   wait-duration: 1s
   retry-exceptions:
     - org.apache.kafka.common.errors.TimeoutException
     - org.apache.kafka.common.errors.NetworkException
   fail-after-max-attempts: true
+  exponential-backoff-multiplier: 2
+  enable-exponential-backoff: true
apps/commerce-streamer/src/main/java/com/loopers/interfaces/dto/ProductLikePayload.java (1)

3-8: LGTM!

Kafka 메시지 페이로드로 적합한 immutable record 구조입니다. eventId를 통해 멱등성 처리가 가능하고, 컴포넌트 구성이 명확합니다.

선택적 고려사항: likeType이 고정된 값 집합(예: LIKE, UNLIKE)이라면 enum 타입으로 변경하여 타입 안전성을 높일 수 있습니다. 단, 외부 시스템과의 호환성이나 확장성을 고려해 String으로 유지하는 것도 합리적인 선택입니다.
apps/commerce-streamer/src/main/java/com/loopers/domain/auditlog/AuditLogService.java (1)
14-21: 매개변수가 많아 유지보수성이 떨어질 수 있습니다.

메서드에 6개의 매개변수가 있어 호출 시 순서를 혼동하기 쉽고, 향후 필드 추가 시 메서드 시그니처가 계속 변경되어야 합니다. 커맨드 객체나 DTO를 도입하여 관련 데이터를 그룹화하는 것을 고려해보세요.
🔎 DTO 패턴 적용 예시
+public record SaveAuditLogCommand(
+    String eventId,
+    Long userId,
+    String actionType,
+    String targetType,
+    Long targetId,
+    String payload
+) {}
+
 @Transactional
-public void saveAuditLog(
-        String eventId,
-        Long userId,
-        String actionType,
-        String targetType,
-        Long targetId,
-        String payload
-) {
-    AuditLog auditLog = AuditLog.create(eventId, userId, actionType, targetType, targetId, payload);
+public void saveAuditLog(SaveAuditLogCommand command) {
+    AuditLog auditLog = AuditLog.create(
+        command.eventId(), 
+        command.userId(), 
+        command.actionType(), 
+        command.targetType(), 
+        command.targetId(), 
+        command.payload()
+    );
     auditLogRepository.save(auditLog);
 }
apps/commerce-api/src/main/java/com/loopers/domain/outbox/OutboxService.java (2)
27-44: 직렬화 실패 시 트랜잭션 처리 전략을 검토하세요.

현재 구현은 JSON 직렬화 실패 시 RuntimeException을 던져 트랜잭션을 롤백시킵니다. 대부분의 경우 적절하지만, 다음 사항들을 고려해보세요:

직렬화 실패가 트랜잭션 롤백을 유발해야 하는지 확인

더 구체적인 커스텀 예외 타입 사용 고려 (예: EventSerializationException)

직렬화 실패한 이벤트를 별도로 추적할 필요성 검토

현재 구현은 동작하지만, 운영 중 직렬화 실패가 발생하면 원본 트랜잭션도 실패하게 됩니다.
🔎 커스텀 예외를 사용한 개선 예시

도메인 레이어에 커스텀 예외 추가:
public class EventSerializationException extends RuntimeException {
    public EventSerializationException(String message, Throwable cause) {
        super(message, cause);
    }
}
서비스 코드 수정:
 } catch (JsonProcessingException e) {
     log.error("Outbox 이벤트 직렬화 실패: aggregateType={}, aggregateId={}",
             aggregateType, aggregateId, e);
-    throw new RuntimeException("이벤트 직렬화 실패", e);
+    throw new EventSerializationException(
+        String.format("이벤트 직렬화 실패: aggregateType=%s, aggregateId=%s", aggregateType, aggregateId), 
+        e
+    );
 }
19-26: 매개변수 수가 많아 실수가 발생하기 쉽습니다.

AuditLogService와 유사하게, 이 메서드도 6개의 매개변수를 받고 있습니다. 커맨드 객체나 빌더 패턴을 도입하면 가독성과 유지보수성이 향상됩니다.
apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventPublisher.java (1)

56-66: 재시도 플로우 명확성 개선 제안

retryFailedEvents 메서드는 실패한 이벤트를 markForRetry()로 표시만 하고, 실제 재전송은 publishPendingEvents가 다시 선택할 때까지 기다립니다. 이 2단계 접근 방식은 의도적 설계로 보이지만, 다음 사항을 고려하세요:

재시도 대기 시간: 최대 5분(fixedDelay) + 1초(publishPendingEvents 주기) 지연 발생

메서드 네이밍: retryFailedEvents는 즉시 재시도를 수행할 것 같은 인상을 주지만 실제로는 마킹만 수행

더 명확한 의도 전달을 위해 메서드명을 markFailedEventsForRetry 또는 Javadoc에 플로우를 명시하는 것을 권장합니다.
apps/commerce-streamer/src/test/java/com/loopers/interfaces/AuditLogConsumerTest.java (1)
17-20: 테스트 코드 품질 양호

테스트 구조가 명확하고 모킹이 적절합니다. ObjectMapper를 매 테스트마다 새로 생성하는 것은 문제없지만, 정적 필드로 추출하면 테스트 간 일관성을 높일 수 있습니다.
🔎 ObjectMapper 정적 필드 추출 제안 (선택사항)
 class AuditLogConsumerTest {
+    private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper();
 
     private final AuditLogFacade facade = mock(AuditLogFacade.class);
-    private final AuditLogConsumer consumer = new AuditLogConsumer(facade, new com.fasterxml.jackson.databind.ObjectMapper());
+    private final AuditLogConsumer consumer = new AuditLogConsumer(facade, OBJECT_MAPPER);
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/ProductViewedEventProducer.java (1)
21-30: Retry 적용은 좋으나 최종 실패 시 처리 고려 필요

Resilience4j @Retry와 fallback 메서드를 적용한 것은 좋은 패턴입니다. 그러나 fallback에서는 로그만 남기고 있어, 재시도 소진 후 이벤트가 완전히 유실됩니다.

상품 조회 이벤트는 주문/결제보다 중요도가 낮을 수 있지만, 다음을 고려하세요:

일관성: PR에서 DLQ 처리를 도입했으므로, 일관성을 위해 producer 실패도 DLQ나 별도 테이블에 기록

모니터링: 실패 이벤트를 집계하여 Kafka 브로커 이슈나 설정 문제를 조기 감지
🔎 DLQ 또는 실패 이벤트 저장 패턴 적용 제안
 public void productViewedFallback(Long productId, Throwable ex) {
     log.error("상품 조회 이벤트 발행 실패 (재시도 후): productId={}", productId, ex);
+    // TODO: DLQ 또는 실패 이벤트 저장 로직 추가 고려
+    // dlqMessageRepository.save(DlqMessage.create(productViewTopic, productId.toString(), event, ex.getMessage()));
 }
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/StockChangedDto.java (1)
5-10: changedType을 Enum으로 변경 권장

changedType 필드가 String으로 정의되어 있어 타입 안전성이 부족합니다. 허용되는 값들(예: "INCREASE", "DECREASE", "SOLD_OUT" 등)을 명시적으로 정의하는 enum을 사용하면 컴파일 타임에 오류를 잡을 수 있고, 코드의 가독성과 유지보수성이 향상됩니다.
🔎 Enum 타입 적용 예시

먼저 enum을 정의합니다:
public enum StockChangeType {
    INCREASE,
    DECREASE,
    SOLD_OUT
}
그리고 record를 수정합니다:
 public record StockChangedDto(
         String eventId,
         Long productId,
         int stock,
-        String changedType
+        StockChangeType changedType
 ) {
-    public static StockChangedDto of(Long productId, int stock, String changedType) {
+    public static StockChangedDto of(Long productId, int stock, StockChangeType changedType) {
         return new StockChangedDto(
                 UUID.randomUUID().toString(),
                 productId,
                 stock,
                 changedType
         );
     }
 }
apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandled.java (1)
29-36: 테스트 용이성을 위해 Clock 주입 고려

Line 34에서 LocalDateTime.now()를 직접 호출하면 테스트 시 시간을 제어하기 어렵고, 타임존 관련 문제가 발생할 수 있습니다. 더 나은 테스트 용이성과 시간 제어를 위해 Clock을 주입받는 방식을 고려해보세요.
🔎 Clock 주입 방식 예시
 @Entity
 @Getter
 @Table(name = "event_handled")
 @NoArgsConstructor(access = AccessLevel.PROTECTED)
 public class EventHandled {

     @Id
     private String eventId;

     @Column(name = "domain_type")
     @Enumerated(EnumType.STRING)
     private EventHandledDomainType domainType;

     @Column(name = "event_type")
     private String eventType;

     @Column(name = "processed_at")
     private LocalDateTime processedAt;

-    public static EventHandled create(String eventId, EventHandledDomainType domainType, String eventType) {
+    public static EventHandled create(String eventId, EventHandledDomainType domainType, String eventType, Clock clock) {
         EventHandled eventHandled = new EventHandled();
         eventHandled.eventId = eventId;
         eventHandled.domainType = domainType;
         eventHandled.eventType = eventType;
-        eventHandled.processedAt = LocalDateTime.now();
+        eventHandled.processedAt = LocalDateTime.now(clock);
         return eventHandled;
     }
 }
서비스 레이어에서 Clock.systemDefaultZone() 또는 테스트용 고정 Clock을 주입하여 사용할 수 있습니다.
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/DlqConsumer.java (1)

46-61: 하드코딩된 에러 메시지

Line 56의 "Message failed after max retries" 메시지가 하드코딩되어 있습니다. 다양한 실패 원인을 구분하거나 다국어 지원이 필요할 경우 설정 파일로 외부화하거나, 상위 레이어에서 전달받는 것을 고려해보세요.

apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/PaymentEventListener.java (1)

57-79: Kafka 발행 실패 시 복구 메커니즘 강화 권장

현재 Kafka 이벤트 발행 실패 시 로깅만 수행하고 있습니다. 프로듀서 레벨에서 @Retry를 통해 재시도가 있더라도, 최종 실패 시 이벤트가 손실될 수 있습니다. PR 설명에서 Outbox 패턴을 언급하셨는데, 다음 중 하나를 고려해주세요:

Outbox 테이블 활용: 이벤트를 DB에 먼저 저장하고 별도 프로세스로 발행

DLT (Dead Letter Topic): 프로듀서 fallback에서 실패 이벤트를 DLT에 저장

보상 트랜잭션 트리거: 발행 실패 시 알림/모니터링 시스템 호출

현재 구조에서는 프로듀서의 fallback 메서드에서 DLT나 outbox에 저장하는 로직을 추가하는 것이 가장 현실적입니다.
apps/commerce-streamer/src/test/java/com/loopers/interfaces/ProductMetricsConsumerTest.java (1)
1-141: 테스트 커버리지 개선 권장

현재 정상 케이스만 테스트되고 있습니다. PR 체크리스트에 언급된 "중복 메시지 재전송 테스트"와 다음 시나리오 추가를 고려해주세요:

파싱 실패: 잘못된 JSON 형식

Null 토픽: Line 42-44의 방어 로직 검증

Facade 예외: processLikeMetrics() 실패 시에도 acknowledge() 호출 확인

멱등성: 동일한 eventId를 가진 중복 메시지 처리
🔎 예시 테스트 추가
@Test
@DisplayName("중복 eventId 메시지 → 멱등성 보장")
void listen_duplicateEventId() {
    // given
    String value = """
        {"eventId": "evt-001", "productId": 123, "likeType": "LIKED"}
        """;
    ConsumerRecord<String, String> record1 = makeRecord("product-like-metrics", "123", value);
    ConsumerRecord<String, String> record2 = makeRecord("product-like-metrics", "123", value);
    
    // when
    consumer.listen(List.of(record1, record2), mock(Acknowledgment.class));
    
    // then - facade는 2번 호출되지만 내부에서 1번만 처리되어야 함
    verify(facade, times(2)).processLikeMetrics(any());
}
apps/commerce-streamer/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsJpaRepository.java (1)
14-15: LGTM - 인덱스 설정 권장

복합키 조회 쿼리가 정확합니다. 다만, productId와 metricsDate를 사용한 빈번한 조회가 예상되므로, ProductMetrics 엔티티에 복합 인덱스 설정을 권장합니다.
@Table(name = "product_metrics", indexes = {
    @Index(name = "idx_product_metrics_lookup", columnList = "product_id, metrics_date")
})
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/AuditLogConsumer.java (1)
40-43: 헤더 값 처리 개선 권장

eventType이 빈 문자열로 초기화되어 있어, 헤더가 없을 때 actionType이 빈 문자열로 설정될 수 있습니다. 이는 의도한 동작일 수 있으나, null 구별이 필요하다면 다음과 같이 개선할 수 있습니다:
🔎 개선안
-String eventType = "";
+String eventType = null;
 if (record.headers().lastHeader("eventType") != null) {
+    byte[] headerValue = record.headers().lastHeader("eventType").value();
+    if (headerValue != null && headerValue.length > 0) {
-        eventType = new String(record.headers().lastHeader("eventType").value(), StandardCharsets.UTF_8);
+        eventType = new String(headerValue, StandardCharsets.UTF_8);
+    }
 }
그리고 Line 68에서:
-node.has("actionType") ? node.get("actionType").asText() : eventType,
+node.has("actionType") ? node.get("actionType").asText() : 
+    (eventType != null ? eventType : "UNKNOWN"),
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/StockChangedEventProducer.java (1)
21-32: 재시도 후 실패 처리 강화 권장

@Retry 애노테이션으로 재시도를 구현했으나, fallback 메서드에서는 로깅만 수행합니다. 재고 변경은 비즈니스 크리티컬한 이벤트이므로, 최종 실패 시 복구 메커니즘을 고려해주세요:

DLT (Dead Letter Topic) 에 이벤트 저장

Outbox 테이블 에 실패 이벤트 기록 후 별도 배치 재처리

알림 시스템 연동
🔎 DLT 저장 예시
public void stockChangedFallback(Long productId, int stock, String changedType, Throwable ex) {
    log.error("재고 변경 이벤트 발행 실패 (재시도 후): productId={}, stock={}, changedType={}",
            productId, stock, changedType, ex);
    
    // DLT에 저장
    try {
        StockChangedDto event = StockChangedDto.of(productId, stock, changedType);
        kafkaTemplate.send(stockChangedTopic + ".DLT", productId.toString(), event);
    } catch (Exception dltEx) {
        log.error("DLT 저장도 실패: productId={}", productId, dltEx);
        // 최후의 수단: DB outbox에 저장
    }
}
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/LikeChangedEventProducer.java (1)
21-31: 일관된 실패 처리 패턴 적용 권장

StockChangedEventProducer와 동일한 구조입니다. 좋아요 이벤트가 재고만큼 크리티컬하지 않을 수 있으나, 일관성과 운영 편의를 위해 동일한 DLQ/Outbox 패턴 적용을 권장합니다.
#!/bin/bash
# 다른 프로듀서들의 fallback 패턴 확인
rg -A 5 "public void.*Fallback" --type java
모든 프로듀서에 일관된 fallback 처리 로직을 적용하면 유지보수가 용이합니다.
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/ProductMetricsConsumer.java (1)
37-58: 배치 처리 시맨틱 확인 필요

개별 메시지 처리 실패 시에도 finally 블록에서 전체 배치를 acknowledge()하고 있습니다. 이는 at-most-once 시맨틱을 제공하며, 실패한 메시지는 재처리되지 않습니다.

PR 설명에서 멱등성 보장을 위해 event_handled 테이블을 사용한다고 했는데, 이 컨슈머에서는 해당 로직이 보이지 않습니다. 다음을 확인해주세요:

ProductMetricsFacade 내부에서 멱등성 보장이 구현되어 있는지

메시지 유실을 허용하는 비즈니스 요구사항인지
#!/bin/bash
# ProductMetricsFacade에서 멱등성 처리 확인
ast-grep --pattern $'class ProductMetricsFacade {
  $$$
  @InboxEvent
  $$$
}'
Based on learnings, @InboxEvent 애노테이션과 EventInboxAspect를 활용한 중앙 에러 처리 패턴 적용을 권장합니다.
apps/commerce-streamer/src/main/java/com/loopers/application/metrics/ProductMetricsCommand.java (1)

7-46: 타입별 커맨드 분리 고려

현재 구조는 metricsType에 따라 일부 필드만 사용되고 나머지는 null입니다. 기능적으로 문제는 없지만, sealed interface와 타입별 record를 사용하면 각 메트릭 타입에 필요한 필드만 명시적으로 갖게 되어 타입 안전성이 향상됩니다.

현재 구현도 간결하고 실용적이므로, 향후 메트릭 타입이 늘어날 경우 리팩토링을 고려해 주세요.
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/UserActionEventProducer.java (2)
21-27: Kafka 전송 결과를 처리하지 않습니다.

kafkaTemplate.send()는 비동기로 동작하며 CompletableFuture를 반환합니다. 현재 코드는 전송 결과를 무시하므로, 전송 실패가 발생해도 @Retry가 트리거되지 않을 수 있습니다. 실패를 감지하려면 결과를 동기적으로 대기하거나 콜백을 등록하는 것을 고려해 주세요.
🔎 전송 결과를 동기적으로 대기하는 방법 제안
 @Retry(name = "kafkaProducer", fallbackMethod = "userActionFallback")
 public void sendUserActionEvent(Long userId, String actionType, String targetType, Long targetId) {
     UserActionDto event = UserActionDto.of(userId, actionType, targetType, targetId);
-    kafkaTemplate.send(userActionTopic, userId.toString(), event);
+    kafkaTemplate.send(userActionTopic, userId.toString(), event).get();
     log.info("유저 행동 이벤트 발행: userId={}, actionType={}, targetType={}, targetId={}",
             userId, actionType, targetType, targetId);
 }
참고: .get() 호출 시 InterruptedException 및 ExecutionException을 처리해야 합니다.
29-31: Fallback 로그에 전체 컨텍스트 포함을 권장합니다.

디버깅을 위해 targetType과 targetId도 로그에 포함하면 문제 추적이 용이해집니다.
🔎 로그 개선 제안
 public void userActionFallback(Long userId, String actionType, String targetType, Long targetId, Throwable ex) {
-    log.error("유저 행동 이벤트 발행 실패 (재시도 후): userId={}, actionType={}", userId, actionType, ex);
+    log.error("유저 행동 이벤트 발행 실패 (재시도 후): userId={}, actionType={}, targetType={}, targetId={}",
+            userId, actionType, targetType, targetId, ex);
 }
apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/DlqMessageService.java (1)
51-75: ID를 찾지 못할 경우 조용히 무시됩니다.

markAsResolved, markAsAbandoned, incrementRetryCount 메서드에서 ID가 존재하지 않을 경우 아무런 동작 없이 종료됩니다. 이는 의도적인 멱등성 설계일 수 있으나, 호출자의 버그를 숨길 위험이 있습니다. 최소한 디버그 로그를 남기거나, 필요시 예외를 던지는 것을 고려해 주세요.
🔎 로깅 추가 예시
 @Transactional
 public void markAsResolved(String id) {
-    dlqMessageRepository.findById(id).ifPresent(message -> {
+    dlqMessageRepository.findById(id).ifPresentOrElse(message -> {
         message.markAsResolved();
         dlqMessageRepository.save(message);
         log.info("DLQ 메시지 해결 완료: id={}", id);
-    });
+    }, () -> log.warn("DLQ 메시지를 찾을 수 없음: id={}", id));
 }
apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetricsService.java (1)

16-39: Magic string 대신 Enum 사용을 고려해 주세요.

likeType("LIKED", "UNLIKED")과 changedType("DECREASED", "RESTORED")이 문자열로 처리되고 있습니다. 타입 안전성과 IDE 지원을 위해 Enum을 사용하면 오타로 인한 버그를 방지할 수 있습니다. Kafka 이벤트 DTO에서 이미 Enum을 사용 중이라면 해당 Enum을 직접 전달하는 것도 방법입니다.
apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/DlqMessage.java (1)
77-85: 상태 전환 시 유효성 검증 누락

markAsResolved()와 markAsAbandoned() 메서드가 현재 상태를 검증하지 않아, ABANDONED → RESOLVED 또는 RESOLVED → ABANDONED로 잘못된 상태 전환이 가능합니다.
🔎 상태 검증 추가 제안
 public void markAsResolved() {
+    if (this.status != DlqStatus.PENDING) {
+        throw new IllegalStateException("PENDING 상태에서만 RESOLVED로 전환할 수 있습니다. 현재 상태: " + this.status);
+    }
     this.status = DlqStatus.RESOLVED;
     this.processedAt = LocalDateTime.now();
 }

 public void markAsAbandoned() {
+    if (this.status != DlqStatus.PENDING) {
+        throw new IllegalStateException("PENDING 상태에서만 ABANDONED로 전환할 수 있습니다. 현재 상태: " + this.status);
+    }
     this.status = DlqStatus.ABANDONED;
     this.processedAt = LocalDateTime.now();
 }
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/PaymentEventDto.java (1)
10-10: 타입 안전성을 위해 String 대신 enum 사용 고려

paymentStatus가 String으로 정의되어 있어 오타나 잘못된 값이 들어갈 수 있습니다. enum을 사용하면 컴파일 타임에 오류를 잡을 수 있습니다.
🔎 enum 적용 예시
public enum PaymentStatus {
    SUCCESS, FAILED, PENDING
}
record 필드를 PaymentStatus paymentStatus로 변경하고, 직렬화 시 @JsonFormat(shape = JsonFormat.Shape.STRING)을 적용할 수 있습니다.
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/OrderEventDto.java (1)
42-44: null 대신 빈 리스트 사용 권장

completed()와 failed() 팩토리 메서드에서 items를 null로 설정하면 Consumer 측에서 NullPointerException이 발생할 수 있습니다. 방어적 프로그래밍을 위해 Collections.emptyList()를 사용하는 것이 안전합니다.
🔎 빈 리스트 적용 예시
 public static OrderEventDto completed(Long orderId, Long userId) {
     return new OrderEventDto(
             UUID.randomUUID().toString(),
             orderId,
             userId,
             "COMPLETED",
             null,
             null,
-            null,
+            List.of(),
             LocalDateTime.now()
     );
 }

 public static OrderEventDto failed(Long orderId, Long userId) {
     return new OrderEventDto(
             UUID.randomUUID().toString(),
             orderId,
             userId,
             "FAILED",
             null,
             null,
-            null,
+            List.of(),
             LocalDateTime.now()
     );
 }
apps/commerce-streamer/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java (2)
27-28: 미사용 상수 존재

PRODUCT_CACHE_KEY_PATTERN 상수가 정의되어 있지만 Line 78에서 동일한 패턴을 인라인으로 작성하고 있습니다. 상수를 사용하거나 불필요한 상수를 제거하세요.
🔎 상수 활용 제안
-    String detailKeyPattern = String.format("product:*:detail:%d", productId);
+    String detailKeyPattern = String.format(PRODUCT_CACHE_KEY_PATTERN, productId);
79-90: Redis KEYS 명령 사용 시 성능 주의 필요

redisTemplate.keys() 메서드는 내부적으로 Redis KEYS 명령을 사용하며, 이는 O(N) 복잡도로 대규모 키스페이스에서 Redis를 블로킹할 수 있습니다. 프로덕션 환경에서 주의가 필요합니다.

또한, Line 86에서 "product:*:list:*" 패턴으로 모든 목록 캐시를 삭제하는 것은 단일 상품 변경에 비해 과도할 수 있습니다.

개선 방안:

SCAN 명령 사용 (RedisTemplate의 scan() 메서드)으로 점진적 조회

상품별 캐시 키 관리를 위한 Redis Set 활용

또는 캐시 TTL에 의존하여 명시적 무효화 최소화
// SCAN 사용 예시
ScanOptions scanOptions = ScanOptions.scanOptions()
    .match(detailKeyPattern)
    .count(100)
    .build();
try (Cursor<String> cursor = redisTemplate.scan(scanOptions)) {
    while (cursor.hasNext()) {
        redisTemplate.delete(cursor.next());
    }
}
apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/OrderEventListener.java (1)
35-36: 사용되지 않는 orderEventProducer 필드가 있습니다.

orderEventProducer가 주입되었지만 이 클래스 내에서 사용되지 않습니다. handleKafkaEventPublish는 직접 Kafka 발행 대신 outboxService를 사용합니다. 의도적으로 outbox 패턴으로 전환한 것이라면, 사용되지 않는 의존성을 제거하세요.
🔎 사용되지 않는 필드 제거 제안
     private final OrderFacade orderFacade;
     private final OutboxService outboxService;
     private final DataPlatformSender dataPlatformSender;
     private final ApplicationEventPublisher eventPublisher;
-    private final OrderEventProducer orderEventProducer;
     private final StockChangedEventProducer stockChangedEventProducer;
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/PaymentEventProducer.java (1)
22-26: 비동기 전송 후 즉시 로깅하면 오해의 소지가 있습니다.

kafkaTemplate.send()는 비동기로 동작하여 CompletableFuture를 반환합니다. 현재 로깅은 실제 전송 완료 전에 "이벤트 발행" 메시지를 출력하므로, 브로커 응답 후 로깅하거나 로그 메시지를 "이벤트 발행 요청"으로 수정하는 것을 권장합니다.
🔎 전송 완료 후 로깅 예시
     public void sendPaymentSuccessEvent(Long orderId, Long userId, String transactionId, Long amount) {
         PaymentEventDto event = PaymentEventDto.success(orderId, userId, transactionId, amount);
-        kafkaTemplate.send(paymentEventsTopic, orderId.toString(), event);
-        log.info("결제 성공 이벤트 발행: orderId={}, transactionId={}", orderId, transactionId);
+        kafkaTemplate.send(paymentEventsTopic, orderId.toString(), event)
+                .whenComplete((result, ex) -> {
+                    if (ex == null) {
+                        log.info("결제 성공 이벤트 발행 완료: orderId={}, transactionId={}", orderId, transactionId);
+                    }
+                });
     }

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1cda434 and 2fc3189.

📒 Files selected for processing (68)

apps/commerce-api/build.gradle.kts (2 hunks)
apps/commerce-api/src/main/java/com/loopers/application/order/OrderFacade.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/domain/outbox/OutboxEvent.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/domain/outbox/OutboxEventRepository.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/domain/outbox/OutboxService.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/domain/payment/event/PaymentSucceededEvent.java (2 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/LikeChangedDto.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/OrderEventDto.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/PaymentEventDto.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/ProductViewedDto.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/StockChangedDto.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/UserActionDto.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/LikeChangedEventProducer.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/OrderEventProducer.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/PaymentEventProducer.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/ProductViewedEventProducer.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/StockChangedEventProducer.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/UserActionEventProducer.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventJpaRepository.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventPublisher.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventRepositoryImpl.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/OrderEventListener.java (4 hunks)
apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/PaymentEventListener.java (4 hunks)
apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/ProductLikeEventListener.java (1 hunks)
apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/UserActionEventListener.java (2 hunks)
apps/commerce-api/src/main/resources/application.yml (2 hunks)
apps/commerce-streamer/src/main/java/com/loopers/application/auditlog/AuditLogCommand.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/application/auditlog/AuditLogFacade.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/application/metrics/MetricsType.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/application/metrics/ProductMetricsCommand.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/auditlog/AuditLog.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/auditlog/AuditLogRepository.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/auditlog/AuditLogService.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/DlqMessage.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/DlqMessageRepository.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/DlqMessageService.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandled.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandledDomainType.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandledRepository.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandledService.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetrics.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetricsId.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetricsRepository.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetricsService.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/infrastructure/auditlog/AuditLogJpaRepository.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/infrastructure/auditlog/AuditLogRepositoryImpl.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/DlqMessageJpaRepository.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/DlqMessageRepositoryImpl.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledJpaRepository.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledRepositoryImpl.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsJpaRepository.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsRepositoryImpl.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/AuditLogConsumer.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/DemoKafkaConsumer.java (0 hunks)
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/DlqConsumer.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/ProductMetricsConsumer.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/interfaces/dto/ProductLikePayload.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/interfaces/dto/ProductStockPayload.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/interfaces/dto/ProductViewPayload.java (1 hunks)
apps/commerce-streamer/src/main/java/com/loopers/support/config/TimeConfig.java (1 hunks)
apps/commerce-streamer/src/main/resources/application.yml (1 hunks)
apps/commerce-streamer/src/test/java/com/loopers/CommerceStreamerContextTest.java (1 hunks)
apps/commerce-streamer/src/test/java/com/loopers/interfaces/AuditLogConsumerTest.java (1 hunks)
apps/commerce-streamer/src/test/java/com/loopers/interfaces/DlqConsumerTest.java (1 hunks)
apps/commerce-streamer/src/test/java/com/loopers/interfaces/ProductMetricsConsumerTest.java (1 hunks)
modules/kafka/src/main/java/com/loopers/confg/kafka/KafkaConfig.java (5 hunks)
modules/kafka/src/main/resources/kafka.yml (1 hunks)

💤 Files with no reviewable changes (1)

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/DemoKafkaConsumer.java

🧰 Additional context used

🧠 Learnings (11)

📓 Common learnings

Learnt from: kilian-develop
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 190
File: apps/commerce-streamer/src/main/java/com/loopers/applications/streamer/consumer/product/IncreaseProductViewKafkaConsumer.java:25-35
Timestamp: 2025-12-18T13:24:54.339Z
Learning: In this codebase, Kafka consumers delegate error handling and event tracking to the service layer via EventInboxAspect. Service methods annotated with InboxEvent are intercepted by the aspect, which handles failures by saving failed EventInbox entries and logging errors. This centralized approach avoids duplicating error handling logic across multiple consumers.

📚 Learning: 2025-11-12T13:04:50.782Z

Learnt from: kilian-develop
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 72
File: core/domain/src/main/java/com/loopers/core/domain/productlike/vo/ProductLikeId.java:5-7
Timestamp: 2025-11-12T13:04:50.782Z
Learning: In the com.loopers codebase, domain entity ID value objects (e.g., ProductLikeId, OrderItemId, ProductId, PaymentId, OrderId, BrandId) are system-generated identifiers and do not require pattern validation (regex, length checks). They are implemented as simple records with a String value and an empty() factory method returning null for unsaved entities. This differs from UserIdentifier, which is a user-supplied login ID that requires format validation. Domain IDs should not be flagged for missing validation logic in the create() method.
<!-- [add_learning]
UserIdentifier와 같은 사용자 입력 ID와 ProductLikeId, OrderItemId 등의 도메인 ID는 검증 패턴이 다릅니다. UserIdentifier는 사용자가 입력하는 로그인 ID로서 정규식, 길이 등의 형식 검증이 필요하지만, 도메인 ID는 시스템에서 생성하는 식별자(UUID, DB 생성 ID)이므로 패턴 검증이 불필요합니다. 도메인 ID VO는 단순한 record와 empty() 팩토리 메서드만으로 충분합니다.

Applied to files:

apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetricsId.java
apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetrics.java

📚 Learning: 2025-11-09T10:41:39.297Z

Learnt from: ghojeong
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 25
File: apps/commerce-api/src/main/kotlin/com/loopers/domain/product/ProductRepository.kt:1-12
Timestamp: 2025-11-09T10:41:39.297Z
Learning: In this codebase, domain repository interfaces are allowed to use Spring Data's org.springframework.data.domain.Page and org.springframework.data.domain.Pageable types. This is an accepted architectural decision and should not be flagged as a DIP violation.

Applied to files:

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/auditlog/AuditLogJpaRepository.java
apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/DlqMessageJpaRepository.java
apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/DlqMessageRepository.java

📚 Learning: 2025-12-18T13:24:51.650Z

Learnt from: kilian-develop
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 190
File: apps/commerce-streamer/src/main/java/com/loopers/applications/streamer/consumer/product/IncreaseProductViewKafkaConsumer.java:25-35
Timestamp: 2025-12-18T13:24:51.650Z
Learning: Adopt centralized error handling for Kafka consumers by using the EventInboxAspect to intercept methods annotated with InboxEvent. Ensure that service methods annotated with InboxEvent save failed EventInbox entries and log errors, avoiding duplicating error handling logic in individual consumers. Apply this pattern broadly to similar consumer/service layers within the commerce-streamer module.

Applied to files:

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/ProductMetricsConsumer.java
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/DlqConsumer.java
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/AuditLogConsumer.java

📚 Learning: 2025-12-18T13:24:54.339Z

Learnt from: kilian-develop
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 190
File: apps/commerce-streamer/src/main/java/com/loopers/applications/streamer/consumer/product/IncreaseProductViewKafkaConsumer.java:25-35
Timestamp: 2025-12-18T13:24:54.339Z
Learning: In this codebase, Kafka consumers delegate error handling and event tracking to the service layer via EventInboxAspect. Service methods annotated with InboxEvent are intercepted by the aspect, which handles failures by saving failed EventInbox entries and logging errors. This centralized approach avoids duplicating error handling logic across multiple consumers.

Applied to files:

apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/OrderEventListener.java
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/OrderEventProducer.java
modules/kafka/src/main/java/com/loopers/confg/kafka/KafkaConfig.java
apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventPublisher.java
apps/commerce-api/src/main/resources/application.yml
apps/commerce-api/src/main/java/com/loopers/domain/outbox/OutboxService.java
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/ProductViewedEventProducer.java
apps/commerce-streamer/src/test/java/com/loopers/interfaces/DlqConsumerTest.java
apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/PaymentEventListener.java
apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/PaymentEventProducer.java

📚 Learning: 2025-11-20T13:22:51.519Z

Learnt from: kilian-develop
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 98
File: core/domain/src/main/java/com/loopers/core/domain/order/DefaultCoupon.java:15-62
Timestamp: 2025-11-20T13:22:51.519Z
Learning: In the order domain coupon implementation, DefaultCoupon serves as an internal helper/DTO class to carry AbstractCoupon's base fields during database reconstruction. It is used as an intermediate object when converting CouponEntity to specific coupon types (RateDiscountCoupon or AmountDiscountCoupon). The actual discount information (rate/amount) is stored in separate tables (rate_discount_coupon and amount_discount_coupon) and fetched via RateDiscountCouponJpaRepository and AmountDiscountCouponJpaRepository. DefaultCoupon is never returned to callers directly.

Applied to files:

apps/commerce-api/src/main/java/com/loopers/application/order/OrderFacade.java

📚 Learning: 2025-11-09T10:49:10.381Z

Learnt from: ghojeong
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 25
File: apps/commerce-api/src/main/kotlin/com/loopers/domain/order/OrderQueryService.kt:9-12
Timestamp: 2025-11-09T10:49:10.381Z
Learning: In this codebase, Service classes (classes whose name contains "Service") are allowed to use Spring's Service annotation, even when located in the domain layer. This is an accepted architectural decision and should not be flagged as a DIP violation.

Applied to files:

apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandledService.java
apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/DlqMessageService.java

📚 Learning: 2025-12-18T01:01:55.894Z

Learnt from: jikimee64
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 65
File: modules/kafka/src/main/resources/kafka.yml:25-32
Timestamp: 2025-12-18T01:01:55.894Z
Learning: In Spring Boot Kafka configuration YAML, properties inside spring.kafka.producer.properties and spring.kafka.consumer.properties maps must use exact Kafka client property names with dot notation, and must be quoted with bracket notation like "[enable.idempotence]": true and "[enable.auto.commit]": false to prevent YAML from parsing dots as nested keys. Spring Boot's relaxed binding only applies to top-level Spring Kafka properties, not to the properties map.

Applied to files:

modules/kafka/src/main/java/com/loopers/confg/kafka/KafkaConfig.java
apps/commerce-api/src/main/resources/application.yml
modules/kafka/src/main/resources/kafka.yml
apps/commerce-streamer/src/main/resources/application.yml

📚 Learning: 2025-11-27T09:09:24.961Z

Learnt from: sky980221
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 121
File: apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductJpaRepository.java:22-24
Timestamp: 2025-11-27T09:09:24.961Z
Learning: Product 엔티티 (apps/commerce-api/src/main/java/com/loopers/domain/product/Product.java)는 유즈케이스별로 의도적으로 다른 락 전략을 사용한다: 좋아요 기능에는 비관적 락(findByIdForUpdate)을, 재고 차감에는 낙관적 락(Version + 재시도)을 사용한다.

Applied to files:

apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/ProductLikeEventListener.java
apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetrics.java

📚 Learning: 2025-12-02T08:12:06.383Z

Learnt from: junoade
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 0
File: :0-0
Timestamp: 2025-12-02T08:12:06.383Z
Learning: ProductQueryService에서 상품 목록 조회 시 Redis 캐시를 적용했으며, 캐시 키는 brandId, sortType, pageNumber, pageSize의 조합으로 구성되고 TTL은 5분으로 설정되어 있다.

Applied to files:

apps/commerce-streamer/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java

📚 Learning: 2025-12-07T12:45:45.556Z

Learnt from: toongri
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 52
File: apps/commerce-api/src/main/kotlin/com/loopers/domain/payment/Payment.kt:160-181
Timestamp: 2025-12-07T12:45:45.556Z
Learning: In the Payment.confirmPayment method in com.loopers.domain.payment.Payment, the when-branch order is intentionally designed with business logic checks before timeout: (1) check SUCCESS/FAILED status first, (2) check for null match (business failure), (3) check timeout only as last resort for PENDING transactions. If matched transaction is PENDING and not timed out, no branch matches and payment stays IN_PROGRESS for scheduler retry. This design prioritizes business outcome determination over time-based fallback.

Applied to files:

apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/PaymentEventListener.java

🧬 Code graph analysis (7)

apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/DlqMessage.java (2)

pg-simulator/src/main/kotlin/com/loopers/domain/payment/Payment.kt (1)

name (14-87)

pg-simulator/src/main/kotlin/com/loopers/support/error/ErrorType.kt (1)

status (5-11)

apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventRepositoryImpl.java (1)

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/DlqMessageRepositoryImpl.java (1)

RequiredArgsConstructor (10-44)

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsRepositoryImpl.java (1)

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/DlqMessageRepositoryImpl.java (1)

RequiredArgsConstructor (10-44)

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledRepositoryImpl.java (1)

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/DlqMessageRepositoryImpl.java (1)

RequiredArgsConstructor (10-44)

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/auditlog/AuditLogRepositoryImpl.java (1)

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/DlqMessageRepositoryImpl.java (1)

RequiredArgsConstructor (10-44)

apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/DlqMessageService.java (1)

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/DlqMessageRepositoryImpl.java (1)

RequiredArgsConstructor (10-44)

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/DlqConsumer.java (1)

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/DlqMessageRepositoryImpl.java (1)

RequiredArgsConstructor (10-44)

🔇 Additional comments (45)

modules/kafka/src/main/java/com/loopers/confg/kafka/KafkaConfig.java (2)

38-41: DLQ 상수 정의 적절합니다.

재시도 간격 1초, 최대 3회 재시도 설정이 명확하게 상수로 정의되어 있습니다.

87-109: 배치 리스너와 에러 핸들러 통합 확인 필요

배치 리스너(setBatchListener(true))와 DefaultErrorHandler 조합 시, 배치 내 단일 레코드 실패 시 전체 배치가 재시도됩니다. 이는 의도된 동작인지 확인이 필요합니다.

만약 개별 레코드 단위 재시도가 필요하다면, 서비스 레이어에서 개별 처리 또는 FallbackBatchErrorHandler 사용을 고려하세요.

apps/commerce-api/src/main/java/com/loopers/application/order/OrderFacade.java (1)

93-96: 멱등성 가드 추가 승인

쿠폰 중복 사용을 방지하는 멱등성 체크가 잘 구현되었습니다. cancelOrder(112-115줄)와 completeOrder(150-153줄) 메서드의 패턴과 일관성 있게 작성되었고, 낙관적 락(92줄)과 함께 이중 방어를 제공합니다. 이벤트 재처리 시나리오에서 안전성을 보장하는 좋은 방어적 프로그래밍 사례입니다.

apps/commerce-api/build.gradle.kts (1)

5-5: LGTM!

Kafka 모듈 의존성과 테스트 설정이 올바르게 추가되었습니다. testFixtures와 spring-kafka-test를 함께 사용하여 통합 테스트를 지원하는 구성이 적절합니다.

Also applies to: 26-28

apps/commerce-streamer/src/main/java/com/loopers/interfaces/dto/ProductViewPayload.java (1)

3-7: LGTM!

Kafka 메시지 payload를 위한 간결한 record 정의입니다. eventId와 productId 필드 구성이 적절합니다.

apps/commerce-streamer/src/main/resources/application.yml (1)

28-36: Kafka 설정 구성 확인됨

토픽 이름과 consumer group 설정이 적절하게 정의되었습니다.

apps/commerce-streamer/src/main/java/com/loopers/application/auditlog/AuditLogCommand.java (1)

11-20: 팩토리 메서드에서 대부분의 필드가 null로 설정됨

of() 메서드가 eventId, userId, targetType, targetId를 모두 null로 설정합니다. 이 필드들이 downstream 처리(예: AuditLogService, AuditLog.create())에서 필수인 경우 NullPointerException이 발생할 수 있습니다. 실제 사용처에서 null 허용 여부를 확인해 주세요.

apps/commerce-streamer/src/main/java/com/loopers/domain/auditlog/AuditLog.java (1)

10-58: LGTM!

JPA 엔티티 구조가 적절하게 설계되었습니다. eventId에 unique 제약 조건이 있어 중복 처리 방지에 효과적이며, payload에 TEXT 타입을 사용한 것도 적절합니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/LikeChangedDto.java (1)

5-17: LGTM!

이벤트 DTO 구조가 적절합니다. UUID.randomUUID()를 사용한 eventId 생성이 적합하며, 팩토리 메서드 패턴이 일관성 있게 적용되었습니다.

apps/commerce-api/src/main/java/com/loopers/domain/outbox/OutboxEvent.java (2)

54-74: Outbox 패턴 구현이 잘 되어 있습니다.

팩토리 메서드 패턴을 사용하여 일관된 초기 상태(PENDING, retryCount=0)를 보장하고, UUID 기반 ID 생성으로 분산 환경에서의 충돌을 방지합니다.

테스트 용이성을 위해 Clock을 주입받는 방식도 고려할 수 있으나, Outbox 이벤트의 경우 생성 시점 기록이 주 목적이므로 현재 구현도 적절합니다.

81-89: 상태 전이 메서드 검토

markAsFailed에서 retryCount를 증가시키고, markForRetry에서는 상태만 PENDING으로 변경하는 것은 적절합니다. 다만 markForRetry 호출 시 lastError를 초기화하지 않는 것이 의도된 것인지 확인이 필요합니다. 디버깅 목적으로 유지하는 것이라면 현재 구현이 맞습니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/auditlog/AuditLogRepository.java (1)

3-6: LGTM!

도메인 레이어에 포트 인터페이스를 정의하고, 인프라스트럭처 레이어에서 구현하는 헥사고날 아키텍처 패턴을 잘 따르고 있습니다.

apps/commerce-streamer/src/main/java/com/loopers/application/metrics/MetricsType.java (1)

3-7: LGTM!

메트릭 타입을 enum으로 정의하여 타입 안전성을 보장합니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandledDomainType.java (1)

3-6: LGTM!

이벤트 처리 도메인 타입을 enum으로 정의하여 타입 안정성을 확보했습니다. 멱등성 처리 시 도메인별 분류에 적합한 구조입니다.

apps/commerce-streamer/src/test/java/com/loopers/CommerceStreamerContextTest.java (1)

6-13: LGTM!

Spring 컨텍스트 로드 테스트로 Kafka 설정 및 빈 와이어링 검증에 유용합니다. 새로운 Kafka 관련 빈들이 정상적으로 초기화되는지 확인하는 기본적인 스모크 테스트입니다.

apps/commerce-api/src/main/resources/application.yml (1)

46-53: LGTM!

Kafka 토픽 네이밍이 일관되고 명확합니다. 이벤트 유형별로 토픽이 잘 분리되어 있어 향후 확장 및 관리에 용이합니다.

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/auditlog/AuditLogJpaRepository.java (1)

1-7: LGTM!

표준 Spring Data JPA 레포지토리 인터페이스로, audit log 영속화를 위한 깔끔한 구현입니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/ProductViewedDto.java (1)

5-14: LGTM!

Record 기반 DTO와 정적 팩토리 메서드를 사용한 구현이 깔끔합니다. UUID를 이용한 eventId 생성은 분산 환경에서 이벤트 고유성을 보장하기에 적절합니다.

apps/commerce-api/src/main/java/com/loopers/domain/payment/event/PaymentSucceededEvent.java (1)

15-15: LGTM!

transactionId 필드 추가가 기존 패턴과 일관되게 구현되었습니다. 결제 이벤트에 트랜잭션 식별자를 포함시키는 것은 추적성과 멱등성 보장에 도움이 됩니다.

Also applies to: 26-26

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledJpaRepository.java (1)

6-9: LGTM!

멱등성 구현을 위한 간결한 리포지토리 인터페이스입니다. existsByEventId 메서드는 Spring Data JPA 네이밍 규칙을 따르며, PR 목표에 명시된 대로 중복 이벤트 처리를 방지하는 데 사용됩니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandledService.java (1)

13-22: LGTM!

멱등성 보장을 위한 잘 설계된 서비스입니다:

조회 메서드에 readOnly = true 트랜잭션 적용으로 성능 최적화

쓰기 메서드는 별도 트랜잭션으로 분리

팩토리 메서드를 통한 엔티티 생성으로 일관성 유지

학습된 바와 같이, 이 코드베이스에서는 도메인 계층의 Service 클래스에 @Service 어노테이션 사용이 허용됩니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetricsRepository.java (1)

6-11: LGTM!

깔끔한 리포지토리 인터페이스입니다. Optional 반환 타입 사용과 메서드 네이밍이 적절하며, 학습된 바와 같이 이 코드베이스에서는 도메인 리포지토리에서 Spring Data 타입 사용이 허용됩니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandledRepository.java (1)

1-8: LGTM!

이벤트 중복 처리 방지를 위한 리포지토리 인터페이스가 명확하고 간결합니다. existsByEventId와 save 메서드로 멱등성 보장에 필요한 최소한의 API만 제공하고 있습니다.

apps/commerce-api/src/main/java/com/loopers/domain/outbox/OutboxEventRepository.java (1)

1-9: LGTM!

Outbox 패턴을 지원하는 리포지토리 인터페이스가 잘 설계되었습니다. 대기 중인 이벤트 조회(findPendingEvents)와 재시도 대상 조회(findFailedEventsForRetry)를 위한 쿼리 메서드가 적절합니다.

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsRepositoryImpl.java (1)

11-26: LGTM!

리포지토리 구현체가 JPA 리포지토리로 단순 위임하는 패턴을 따르고 있습니다. 코드베이스의 다른 리포지토리 구현체(예: DlqMessageRepositoryImpl)와 일관된 구조를 유지하고 있어 좋습니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/UserActionDto.java (1)

5-21: LGTM!

사용자 액션 이벤트를 위한 DTO가 간결하고 명확합니다. of() 팩토리 메서드에서 UUID를 자동 생성하여 이벤트 ID 중복을 방지하는 것이 좋습니다. Record 사용으로 불변성도 보장됩니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/StockChangedDto.java (1)

11-18: LGTM!

UUID를 사용한 eventId 생성 방식이 적절하며, 팩토리 메서드 구현이 명확합니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandled.java (1)

10-28: LGTM!

엔티티 구조가 명확하고 JPA 매핑이 적절합니다. Enum을 STRING으로 저장하는 방식도 가독성 측면에서 좋은 선택입니다.

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/auditlog/AuditLogRepositoryImpl.java (1)

8-17: LGTM!

표준 리포지토리 구현 패턴을 잘 따르고 있으며, JpaRepository로의 위임이 적절합니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetricsId.java (1)

13-32: LGTM!

복합 키 구현이 적절합니다. Serializable 구현, @Embeddable 애노테이션, 그리고 @EqualsAndHashCode 사용이 JPA 복합 키 요구사항을 충족합니다.

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledRepositoryImpl.java (1)

8-23: LGTM!

리포지토리 구현이 프로젝트의 표준 패턴을 잘 따르고 있으며, 깔끔하게 JpaRepository로 위임하고 있습니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/dlq/DlqMessageRepository.java (1)

6-19: LGTM!

리포지토리 인터페이스가 명확하고 DLQ 메시지 처리에 필요한 메서드들이 잘 정의되어 있습니다.

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/DlqConsumer.java (1)

63-68: LGTM!

토픽명 추출 로직이 명확하고 간단합니다. .DLT 접미사를 제거하는 방식이 적절합니다.

apps/commerce-streamer/src/test/java/com/loopers/interfaces/DlqConsumerTest.java (3)

17-26: LGTM!

테스트 설정이 깔끔하고, mock 사용이 적절합니다. makeRecord 헬퍼 메서드로 중복을 줄인 것도 좋습니다.

149-175: 테스트가 현재 구현을 정확히 검증하지만, DlqConsumer 수정 시 업데이트 필요

이 테스트는 현재 DlqConsumer의 동작(저장 실패 시에도 acknowledge 호출)을 정확히 검증합니다. 그러나 DlqConsumer.java에서 제기한 크리티컬 이슈(저장 실패 시 무조건 acknowledge)가 수정되면, 이 테스트도 함께 업데이트되어야 합니다.

28-142: LGTM!

테스트 커버리지가 매우 포괄적입니다. 단일 메시지, 배치 처리, 파라미터 전달, 토픽 추출 등 모든 주요 시나리오를 잘 검증하고 있으며, ArgumentCaptor를 활용한 검증 방식도 적절합니다.

Also applies to: 194-226

apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/PaymentEventListener.java (1)

141-162: LGTM - 실패 이벤트 발행 로직

결제 실패 이벤트를 Kafka로 발행하는 로직이 적절합니다. 앞서 코멘트한 복구 메커니즘 강화 사항이 이 메서드에도 동일하게 적용됩니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetrics.java (1)

28-55: LGTM!

팩토리 메서드와 뮤테이터 메서드가 명확하게 구현되어 있습니다. 델타 기반 메트릭 추적 설계로, 증감 연산이 적절합니다.

apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/UserActionEventListener.java (1)

55-73: LGTM!

publishKafkaEvent 메서드의 에러 처리가 적절합니다. PRODUCT_VIEW 이벤트를 메트릭용과 감사 로그용 토픽에 각각 발행하는 설계도 명확합니다.

apps/commerce-streamer/src/main/java/com/loopers/infrastructure/dlq/DlqMessageRepositoryImpl.java (1)

15-43: 위임 구현 LGTM!

JPA 리포지토리로의 위임 패턴이 깔끔하게 구현되어 있습니다. findPendingMessagesForRetry에서 재시도 대상 메시지를 조회하는 로직도 적절합니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventRepositoryImpl.java (1)

10-29: LGTM!

Repository 구현이 깔끔하고, JPA 레포지토리에 대한 위임 패턴이 DlqMessageRepositoryImpl과 일관성 있게 작성되었습니다.

apps/commerce-streamer/src/main/java/com/loopers/domain/metrics/ProductMetricsService.java (1)

48-51: LGTM!

getOrCreateMetrics 헬퍼 메서드가 깔끔하게 추출되었고, 모든 호출자가 수정 후 save()를 호출하여 올바르게 동작합니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/OrderEventProducer.java (1)

50-65: Fallback에서 이벤트 지속성 처리 고려

Fallback 메서드가 현재 로그만 남기고 있습니다. 재시도 실패 시 이벤트가 유실될 수 있으므로, Outbox 패턴과 연계하거나 별도 저장소에 실패 이벤트를 저장하는 것을 고려해 주세요.

PR 설명에 Outbox 패턴이 언급되어 있는데, 이 Producer가 Outbox를 통해 호출되는지, 또는 실패 시 재시도를 위한 별도 메커니즘이 있는지 확인이 필요합니다.

apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/OrderEventListener.java (1)

96-124: Outbox 패턴이 올바르게 구현되었습니다.

BEFORE_COMMIT 단계에서 outbox에 저장하여 트랜잭션 일관성을 보장합니다. orderId를 partition key로 사용하여 동일 주문의 이벤트 순서를 보장하는 설계가 적절합니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/PaymentEventProducer.java (1)

14-19: 전반적인 구조가 적절합니다.

@RequiredArgsConstructor를 통한 의존성 주입과 @Value를 통한 토픽 설정 분리가 잘 되어 있습니다. orderId를 partition key로 사용하여 동일 주문의 결제 이벤트 순서를 보장하는 설계도 적절합니다.

...mmerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/PaymentEventProducer.java

apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventPublisher.java

apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/OrderEventListener.java

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/DlqConsumer.java

.../commerce-streamer/src/main/java/com/loopers/interfaces/consumer/ProductMetricsConsumer.java

modules/kafka/src/main/java/com/loopers/confg/kafka/KafkaConfig.java

modules/kafka/src/main/resources/kafka.yml

looper88888 · 2025-12-20T02:41:18Z

✅ Checklist

🎾 Producer
[ ] 도메인(애플리케이션) 이벤트 설계
[ ] Producer 앱에서 도메인 이벤트 발행 (catalog-events, order-events, 등)
[ ] PartitionKey 기반의 이벤트 순서 보장
[ ] 메세지 발행이 실패했을 경우에 대해 고민해보기

⚾ Consumer
[ ] Consumer 가 Metrics 집계 처리
[ ] event_handled 테이블을 통한 멱등 처리 구현
[ ] 재고 소진 시 상품 캐시 갱신
[ ] 중복 메세지 재전송 테스트 → 최종 결과가 한 번만 반영되는지 확인

@coderabbitai 체크리스트 확인해

coderabbitai · 2025-12-20T02:43:05Z

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check domain event DTOs structure and design
echo "=== 1. Event DTOs (Domain Event Design) ==="
fd -e java -p "EventDto" apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/dto/ --exec cat {}

echo -e "\n=== 2. Producer Partition Key Usage ==="
# Check how producers use partition keys
rg -A 5 "kafkaTemplate.send" apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/

echo -e "\n=== 3. Retry and Fallback Configuration ==="
# Check retry annotations and fallback methods
rg "@Retry|fallback" apps/commerce-api/src/main/java/com/loopers/infrastructure/kafka/producer/

echo -e "\n=== 4. EventHandled Implementation ==="
# Check event_handled usage in consumers
cat apps/commerce-streamer/src/main/java/com/loopers/domain/eventhandled/EventHandled.java

echo -e "\n=== 5. EventHandled Service Usage ==="
rg "eventHandledService|EventHandledService" apps/commerce-streamer/src/main/java/com/loopers/application/

echo -e "\n=== 6. Cache Invalidation on Stock Change ==="
# Check cache invalidation in ProductMetricsFacade
cat apps/commerce-streamer/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java | grep -A 30 "processStockMetrics\|invalidateProductCache"

echo -e "\n=== 7. Idempotency Tests ==="
# Look for duplicate message tests
rg -l "duplicate|idempotent|event.*handled" apps/commerce-streamer/src/test/

Length of output: 19677

🏁 Script executed:

#!/bin/bash
# Check Outbox pattern for publish failure handling
echo "=== Outbox Pattern for Failure Handling ==="
cat apps/commerce-api/src/main/java/com/loopers/infrastructure/outbox/OutboxEventPublisher.java | head -80

echo -e "\n=== Resilience4j Retry Configuration ==="
cat apps/commerce-api/src/main/resources/application.yml | grep -A 10 "kafkaProducer:"

Length of output: 2612

🏁 Script executed:

#!/bin/bash
# Check test files for duplicate message/idempotency testing
echo "=== Consumer Test - Duplicate Message Handling ==="
cat apps/commerce-streamer/src/test/java/com/loopers/interfaces/ProductMetricsConsumerTest.java | grep -B 5 -A 20 "batch\|duplicate"

echo -e "\n=== Facade Idempotency Check in Tests ==="
rg "isEventHandled|processAuditLog|processLikeMetrics|processStockMetrics" apps/commerce-streamer/src/test/ -A 5

echo -e "\n=== Domain Event Listeners (Order events) ==="
cat apps/commerce-api/src/main/java/com/loopers/interfaces/api/listener/OrderEventListener.java | grep -B 3 -A 10 "@EventListener\|@TransactionalEventListener"

Length of output: 9375

@looper88888 체크리스트를 확인했습니다! 각 항목별로 구현 상태를 정리했어요.

🎾 Producer 체크리스트 (4/4 완료)

✅ 도메인(애플리케이션) 이벤트 설계

OrderEventDto, PaymentEventDto, StockChangedDto, LikeChangedDto, ProductViewedDto, UserActionDto 등 잘 설계됨
각 DTO에 factory 메서드 (.created(), .success() 등) 제공

✅ Producer 앱에서 도메인 이벤트 발행

OrderEventProducer: 주문 생성/완료/실패 이벤트
PaymentEventProducer: 결제 성공/실패/대기 이벤트
StockChangedEventProducer: 재고 변경 이벤트
LikeChangedEventProducer: 좋아요 변경 이벤트
ProductViewedEventProducer: 상품 조회 이벤트
UserActionEventProducer: 유저 행동 이벤트

✅ PartitionKey 기반의 이벤트 순서 보장

// 모든 Producer에서 일관된 키 사용
kafkaTemplate.send(topic, orderId.toString(), event);      // Order/Payment
kafkaTemplate.send(topic, productId.toString(), event);    // Product
kafkaTemplate.send(topic, userId.toString(), event);       // User

✅ 메세지 발행이 실패했을 경우에 대해 고민해보기

Resilience4j Retry: 모든 Producer 메서드에 @Retry(name = "kafkaProducer") 적용 (3회 재시도, 1초 대기)
Fallback 메서드: 재시도 실패 시 로깅 및 에러 핸들링
Outbox 패턴: OutboxEventPublisher가 1초마다 실패한 이벤트를 재발행 (최대 5회 재시도)
DLQ 처리: DeadLetterPublishingRecoverer로 최종 실패 메시지를 .DLT 토픽으로 전송

⚾ Consumer 체크리스트 (4/4 완료)

✅ Consumer 가 Metrics 집계 처리

ProductMetricsConsumer → ProductMetricsFacade → ProductMetricsService
Like/Stock/View 메트릭을 product_metrics 테이블에 집계
각 메트릭별로 delta 필드 (likesDelta, salesDelta, viewsDelta) 업데이트

✅ event_handled 테이블을 통한 멱등 처리 구현

// ProductMetricsFacade, AuditLogFacade 모두 동일한 패턴 적용
if (eventHandledService.isEventHandled(command.eventId())) {
    return;  // 이미 처리된 이벤트는 스킵
}
// ... 비즈니스 로직 처리 ...
eventHandledService.saveEventHandled(command.eventId(), DOMAIN_TYPE, eventType);

✅ 재고 소진 시 상품 캐시 갱신

public void processStockMetrics(ProductMetricsCommand command) {
    // ... 메트릭 처리 ...
    invalidateProductCache(command.productId());  // 캐시 무효화
}

private void invalidateProductCache(Long productId) {
    // 상품 상세 캐시 삭제: product:*:detail:{productId}
    // 상품 목록 캐시 삭제: product:*:list:*
}

⚠️ 중복 메세지 재전송 테스트 → 최종 결과가 한 번만 반영되는지 확인

현재 상태: Unit 테스트가 존재하지만 실제 중복 메시지 시나리오는 테스트하지 않음
ProductMetricsConsumerTest는 Consumer → Facade 호출만 검증
권장사항: Integration 테스트 추가 필요

// 추천하는 테스트 시나리오
@Test
void 동일한_eventId_두번_전송시_한번만_처리됨() {
    String sameEventId = "evt-duplicate-001";
    
    // 첫 번째 전송
    consumer.listen(record(sameEventId), ack);
    
    // 두 번째 전송 (중복)
    consumer.listen(record(sameEventId), ack);
    
    // 검증: event_handled 테이블에 1개만 존재
    // 검증: metrics 값이 1번만 증가
}

📝 요약

완료된 항목: 8개 중 8개 ✅
주의 사항: 중복 메시지 테스트는 통합 테스트로 보완하면 더 좋습니다.

전반적으로 Kafka 통합이 매우 잘 구현되어 있습니다! 특히 Outbox 패턴, DLQ 처리, EventHandled 기반 멱등성 구현이 인상적이네요 👍

🧠 Learnings used

Learnt from: toongri
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 68
File: docs/week8/round8-detailed-design.md:151-178
Timestamp: 2025-12-19T20:59:50.009Z
Learning: In the Loopers-dev-lab/loopers-spring-kotlin-template repository's Kafka event pipeline, only 5 domain events are intentionally published to Kafka via CloudEventEnvelopeFactory: OrderPaidEventV1, LikeCreatedEventV1, LikeCanceledEventV1, ProductViewedEventV1, and StockDepletedEventV1. Other domain events (OrderCreatedEventV1, OrderCanceledEventV1, PaymentCreatedEventV1, PaymentPaidEventV1, PaymentFailedEventV1) are internal-only and intentionally not mapped in resolveMetadata(), which correctly returns null for them to exclude them from Outbox publication.

Learnt from: toongri
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 68
File: apps/commerce-streamer/src/main/kotlin/com/loopers/interfaces/consumer/product/ProductEventConsumer.kt:0-0
Timestamp: 2025-12-19T23:39:16.424Z
Learning: In Loopers-dev-lab/loopers-spring-kotlin-template, toongri prefers pragmatic idempotency handling in Kafka consumers: when idempotency key persistence fails after successful business logic execution, log a warning and continue (accepting low risk of duplicates on retry) rather than rolling back business data. This keeps business logic decoupled from idempotency store (which might be Redis/external system, not RDB), avoids over-engineering for rare edge cases, and prioritizes core business value over auxiliary metadata. Transaction-based atomicity between business data and idempotency keys is considered excessive when duplicate event probability is very low.

Learnt from: toongri
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 68
File: apps/commerce-api/src/main/kotlin/com/loopers/infrastructure/outbox/OutboxEventListener.kt:0-0
Timestamp: 2025-12-19T21:30:08.018Z
Learning: In the Loopers-dev-lab/loopers-spring-kotlin-template Kafka event pipeline, Like events (LikeCreatedEventV1, LikeCanceledEventV1) intentionally use aggregateType="Like" with aggregateId=productId. The aggregateId serves as a partitioning/grouping key (not a unique Like entity identifier), ensuring all like events for the same product go to the same partition for ordering guarantees and aligning with ProductStatisticService's product-based aggregation logic. Using individual like_id would scatter events across partitions and break the statistics aggregation pattern.

Learnt from: kilian-develop
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 190
File: apps/commerce-streamer/src/main/java/com/loopers/applications/streamer/consumer/product/IncreaseProductViewKafkaConsumer.java:25-35
Timestamp: 2025-12-18T13:24:54.339Z
Learning: In this codebase, Kafka consumers delegate error handling and event tracking to the service layer via EventInboxAspect. Service methods annotated with InboxEvent are intercepted by the aspect, which handles failures by saving failed EventInbox entries and logging errors. This centralized approach avoids duplicating error handling logic across multiple consumers.

rnqhstmd added 30 commits December 19, 2025 13:42

feat: Kafka 모듈 추가 및 테스트 의존성 설정

4fec7e4

feat: Kafka 설정에 idempotence 및 max.in.flight.requests 추가

9766e3a

refactor: 사용하지 않는 클래스 제거

f15071d

feat: Kafka 설정에 Dead Letter Queue 및 오류 처리기 추가

e247031

feat: 주문 생성 시 Kafka 이벤트 발행 및 Outbox 패턴 적용

374fea6

feat: 쿠폰 사용 시 멱등성 처리 추가

f7d89bc

feat: 결제 성공 및 실패 시 Kafka 이벤트 발행 기능 추가

f0a2536

feat: PaymentSucceededEvent에 transactionId 필드 추가

90c4f5e

feat: 유저 행동 이벤트 처리 시 Kafka 이벤트 발행 기능 추가

a8947ea

feat: AuditLog 엔티티 추가 및 생성 메서드 구현

0591b1d

feat: AuditLogCommand 클래스 추가 및 이벤트 생성 메서드 구현

4f9aab7

feat: AuditLogConsumer 클래스 추가 및 Kafka 이벤트 수신 처리 구현

8482be0

feat: AuditLogFacade 클래스 추가 및 감사 로그 처리 메서드 구현

db6ccf2

feat: AuditLogJpaRepository, AuditLogRepository, and AuditLogReposito…

ef7d1e9

…ryImpl 클래스 추가 및 저장 메서드 구현

feat: AuditLogService 클래스 추가 및 감사 로그 저장 메서드 구현

e297043

feat: DlqMessage 클래스 추가 및 DLQ 메시지 처리 메서드 구현

cad42e8

feat: DlqConsumer 클래스 추가 및 DLQ 메시지 수신 처리 메서드 구현

58baa37

feat: DlqMessageJpaRepository, DlqMessageRepository, and DlqMessageRe…

cf5058a

…positoryImpl 클래스 추가 및 DLQ 메시지 처리 메서드 구현

feat: DlqMessageService 클래스 추가 및 DLQ 메시지 처리 메서드 구현

643d5f3

feat: EventHandled 클래스 추가 및 이벤트 처리 메서드 구현

09facd9

feat: EventHandled 타입 추가

e1b347f

feat: EventHandledJpaRepository, EventHandledRepository, and EventHan…

dc8b650

…dledRepositoryImpl 클래스 추가 및 이벤트 처리 메서드 구현

feat: EventHandledService 클래스 추가 및 이벤트 처리 메서드 구현

5d0be8e

feat: LikeChangedDto 및 UserActionDto 클래스 추가 및 이벤트 처리 메서드 구현

c6e9f85

feat: OrderEventDto 클래스 추가 및 주문 이벤트 생성 메서드 구현

07ab357

feat: LikeChangedEventProducer 클래스 추가 및 좋아요 변경 이벤트 발행 메서드 구현

ddf1ec2

feat: MetricsType enum 추가 및 메트릭스 유형 정의

be27697

feat: OrderEventProducer 클래스 추가 및 주문 이벤트 발행 메서드 구현

22f1d7b

feat: OutboxEvent 클래스 추가 및 이벤트 생성, 상태 관리 메서드 구현

f5a08e6

feat: OutboxEventPublisher 클래스 추가 및 Pending 이벤트 발행 및 실패한 이벤트 재시도 메서드 구현

723923d

rnqhstmd added 8 commits December 19, 2025 14:59

feat: TimeConfig 클래스 추가 및 시스템 기본 시간 설정을 위한 Clock 빈 정의

0828dff

feat: UserActionEventProducer 클래스 추가 및 유저 행동 이벤트 발행 로직 구현

2597a71

feat: CommerceStreamerContextTest 클래스 추가 및 컨텍스트 로드 테스트 구현

e4801a9

test: ProductMetricsConsumerTest 클래스 추가 및 제품 메트릭 처리 테스트 구현

5c6dd2e

test: AuditLogConsumerTest 클래스 추가 및 감사 로그 소비자 테스트 구현

26a07ef

test: DlqConsumerTest 클래스 추가 및 DLQ 메시지 소비 로직 테스트 구현

2dd4985

feat: 카프카 토픽 및 컨슈머 그룹 추가

4847130

feat: 카프카 토픽 및 컨슈머 그룹 추가

2fc3189

rnqhstmd self-assigned this Dec 19, 2025

rnqhstmd added the enhancement New feature or request label Dec 19, 2025

coderabbitai bot reviewed Dec 19, 2025

View reviewed changes

rnqhstmd added 12 commits December 19, 2025 17:03

fix: 개선된 DLQ 메시지 처리 로직 및 오류 로깅

57dcf28

fix: yml 코드포멧 변경

88f8d6c

fix: 수정된 DLT 파티션 처리 로직

75469d9

refactor: 사용하지않는 메서 제거

c472a53

feat: 폴백 시 아웃박스 패턴 적용

9a5c84f

feat: 설정 코드 위치 변경

3555228

feat: 도메인 타입으로 검증할 수 있도록 수정

5643063

feat: 상태값으로 조회하는 메서드 추가

a333fbf

feat: Outbox 이벤트 저장을 위한 Kafka 이벤트 리스너 수정

9838f76

feat: Kafka 리스너에 허용된 토픽 검증 로직 추가

f16d113

chore: 도메인 타입 검증 메서드 사용하도록 수정

110c9db

feat: 개선된 오류 처리 로직 추가 및 Kafka 이벤트 발행 실패 로그 수정

5515b9b

rnqhstmd merged commit e7bf613 into Loopers-dev-lab:rnqhstmd Dec 24, 2025
2 checks passed

This was referenced Dec 25, 2025

[volume-9] Product Ranking with Redis #211

Open

[volume - 8] Decoupling with Kafka #206

Merged

[volume-9] Product Ranking with Redis #216

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[volume - 8] Decoupling with Kafka #196

[volume - 8] Decoupling with Kafka #196

Uh oh!

rnqhstmd commented Dec 19, 2025 •

edited by coderabbitai bot

Loading

Uh oh!

coderabbitai bot commented Dec 19, 2025 •

edited

Loading

Review skipped

Uh oh!

coderabbitai bot left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

looper88888 commented Dec 20, 2025

Uh oh!

coderabbitai bot commented Dec 20, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

[volume - 8] Decoupling with Kafka #196

[volume - 8] Decoupling with Kafka #196

Uh oh!

Conversation

rnqhstmd commented Dec 19, 2025 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📌 Summary

💬 Review Points

✅ Checklist

🎾 Producer

⚾ Consumer

Summary by CodeRabbit

릴리스 노트

Uh oh!

coderabbitai bot commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

요약

Walkthrough

Changes

Sequence Diagram(s)

Estimated code review effort

추가 검토 필요 사항:

Possibly related PRs

Poem

Pre-merge checks and finishing touches

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

looper88888 commented Dec 20, 2025

Uh oh!

coderabbitai bot commented Dec 20, 2025

🎾 Producer 체크리스트 (4/4 완료)

⚾ Consumer 체크리스트 (4/4 완료)

📝 요약

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

rnqhstmd commented Dec 19, 2025 •

edited by coderabbitai bot

Loading

coderabbitai bot commented Dec 19, 2025 •

edited

Loading