목적
주문 처리 핵심 흐름(SyncOrderProcessor, AcceptedOrderProcessor)을 읽고 설명할 수 있는 구조로 정리한다. 비즈니스 로직과 계측 코드가 한 줄에 뒤섞여 흐름 파악이 어려운 문제를 해소한다.
배경
성능 측정은 이미 완료되어 README 병목 분석에 반영되었다. 그러나 측정을 위해 추가된 인라인 계측이 핵심 로직을 가린다.
stageRecorder.record("stage", () -> 실제호출) 가 줄마다 감싸 있어 비즈니스 로직이 람다 안에 파묻힘OrderTransactionLifecycleRecorder 가 트랜잭션을 8단계 미세 구간으로 측정 — afterCommit/afterCompletion 콜백마다 transactionMetrics.recordXxx() 호출이 흩어져 있음 (README 미사용)
작업 범위
OrderTransactionLifecycleRecorder 제거 (8단계 트랜잭션 미세 계측)SyncOrderProcessor / AcceptedOrderProcessor 에서 인라인 stageRecorder 호출 제거 → 핵심 흐름이 순차적으로 읽히도록 정리- 계측에만 쓰이던 파라미터(
createStartedAt, processor side) 정리
OrderAssetLockService 내부 계측은 유지 (서비스 경계에 캡슐화되어 흐름을 가리지 않음)MarketOrderCommandQueue 의 command_queue_wait / queue.depth 등 운영 지표는 유지
완료 기준
SyncOrderProcessor.executeInTransaction 이 sequence→wallet lock→save→match→settle→orderbook 순서로 읽힘./gradlew test 통과 (동작/계약 변경 없음)
비범위 (후속)
SyncOrderProcessor/AcceptedOrderProcessor 공통 로직 단일 핸들러 통합- 얇은 래퍼 서비스(
OrderAssetLockService) 정리
목적
주문 처리 핵심 흐름(
SyncOrderProcessor,AcceptedOrderProcessor)을 읽고 설명할 수 있는 구조로 정리한다. 비즈니스 로직과 계측 코드가 한 줄에 뒤섞여 흐름 파악이 어려운 문제를 해소한다.배경
성능 측정은 이미 완료되어 README 병목 분석에 반영되었다. 그러나 측정을 위해 추가된 인라인 계측이 핵심 로직을 가린다.
stageRecorder.record("stage", () -> 실제호출)가 줄마다 감싸 있어 비즈니스 로직이 람다 안에 파묻힘OrderTransactionLifecycleRecorder가 트랜잭션을 8단계 미세 구간으로 측정 — afterCommit/afterCompletion 콜백마다transactionMetrics.recordXxx()호출이 흩어져 있음 (README 미사용)작업 범위
OrderTransactionLifecycleRecorder제거 (8단계 트랜잭션 미세 계측)SyncOrderProcessor/AcceptedOrderProcessor에서 인라인stageRecorder호출 제거 → 핵심 흐름이 순차적으로 읽히도록 정리createStartedAt, processorside) 정리OrderAssetLockService내부 계측은 유지 (서비스 경계에 캡슐화되어 흐름을 가리지 않음)MarketOrderCommandQueue의command_queue_wait/queue.depth등 운영 지표는 유지완료 기준
SyncOrderProcessor.executeInTransaction이 sequence→wallet lock→save→match→settle→orderbook 순서로 읽힘./gradlew test통과 (동작/계약 변경 없음)비범위 (후속)
SyncOrderProcessor/AcceptedOrderProcessor공통 로직 단일 핸들러 통합OrderAssetLockService) 정리