llm-wiki/raw/company-tech-blogs/transaction-port-vassilis-soum-github-readme.md

---
title: "VassilisSoum/spring-custom-transaction-interceptor (GitHub)"
source_type: company-tech-blog
url: https://github.com/VassilisSoum/spring-custom-transaction-interceptor
archive_url:
status: raw
confidence: medium
tags: [ca-transaction-boundary, custom-aop, transaction-interceptor, functional, github-reference]
related_branches: [feature-application-port-usecase-contract, feature-transaction-concurrency-contract]
related_projects: [ca-skeleton-operational-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# spring-custom-transaction-interceptor (GitHub Reference 구현)

> Layer: `raw/company-tech-blogs/` — Vassilis Soum 개인 GitHub repository 의 README 와 코드 발췌. Spring `TransactionInterceptor` 를 확장해 `Try` 모나드와 통합한 reference 구현체.
> 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 별도 작성. 원본은 raw에 영구 보관.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-application-port-usecase-contract]] | functional error 타입을 유지하면서 Spring TX 를 활용하는 대안 (= ca-tmpl 의 정반대 dependency 방향) 의 reference 구현체 근거 |
| [[raw/branch-notes/feature-transaction-concurrency-contract]] | Topic 2 — Transaction Boundary 대안 5 (Custom AOP / TransactionInterceptor 확장) 의 reference 구현체 |
| [[raw/project-notes/ca-skeleton-operational-contract]] | §14. Transaction / Concurrency Contract — TransactionPort 결정의 dependency 방향 비교군 |

## 컨텍스트 / 왜 저장했는지

ca-tmpl 의 TransactionPort 결정에 대한 대안 5 의 **레퍼런스 구현체**. 함수형 에러 타입(Try/Either) 을 유지하면서 Spring 트랜잭션 관리 인프라를 재사용하기 위해 `TransactionInterceptor` 를 직접 확장한 코드.

## 출처 / Source

- 원본 URL: https://github.com/VassilisSoum/spring-custom-transaction-interceptor
- 아카이브 URL: (미수집)
- 저자 / 조직: Vassilis Soum (개인 GitHub, 산업 예제 다수)
- 발행일: 2024
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [§README — TransactionInterceptor 설명] "The TransactionInterceptor is a Spring AOP interceptor that intercepts all methods annotated with the `@Transactional` annotation."

> [§README — Try 모나드 통합 동기] "In this example we use the custom TransactionInterceptor to handle transaction management for the com.soumakis.control.Try monad to be able to express exceptions as types in the method signature."

> [§README — 확장 인터페이스] "The TransactionInterceptor is a custom implementation of the `org.aopalliance.intercept.MethodInterceptor` interface."

> [§README — 핵심 동작] "It is used to intercept method invocations and execute custom logic before and after the method invocation."

> [§README — 설정 요구사항] "In `application.properties` or `application.yml` allow overriding spring beans by setting `spring.main.allow-bean-definition-overriding=true`"

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| VSOUM-TX-C1 | Spring 의 표준 `TransactionInterceptor` 는 `@Transactional` 메서드를 가로채는 AOP 인터셉터이며, 본 repo 는 그것을 확장한 custom 구현체를 제공 | [§README — TransactionInterceptor 설명] "The TransactionInterceptor is a Spring AOP interceptor that intercepts all methods annotated with the `@Transactional` annotation." | `engineering-blog` | Spring AOP + `@Transactional` 환경 | `@Transactional` 외 메타 어노테이션 (`@SpringTransactional` 등 custom) 처리 여부는 본 인용 범위 밖 |
| VSOUM-TX-C2 | 확장 동기는 **`com.soumakis.control.Try` 모나드** 가 Spring TX 와 호환되도록 만들기 위함 — 예외를 메서드 시그니처의 타입으로 표현 가능 | [§README — Try 모나드 통합 동기] "In this example we use the custom TransactionInterceptor to handle transaction management for the com.soumakis.control.Try monad to be able to express exceptions as types in the method signature." | `engineering-blog` | functional error handling + Spring TX | 이 패턴이 모든 functional library (Vavr `Either`, kotlin-result 등) 에서 동작한다는 뜻은 아님 — `Try` 한정 |
| VSOUM-TX-C3 | custom TransactionInterceptor 는 `org.aopalliance.intercept.MethodInterceptor` 인터페이스를 구현하며, 메서드 invocation 전후 custom logic 실행 가능 | [§README — 확장 인터페이스] "The TransactionInterceptor is a custom implementation of the `org.aopalliance.intercept.MethodInterceptor` interface." + "It is used to intercept method invocations and execute custom logic before and after the method invocation." | `engineering-blog` | Spring AOP / aopalliance 기반 인터셉터 확장 | 구현체가 모든 Spring 버전 / Boot 버전에서 호환된다는 뜻은 아님 (API 안정성 별도) |
| VSOUM-TX-C4 | 본 패턴은 **`spring.main.allow-bean-definition-overriding=true`** 설정을 요구 (Spring 의 기본 TransactionInterceptor bean 을 override) | [§README — 설정 요구사항] "In `application.properties` or `application.yml` allow overriding spring beans by setting `spring.main.allow-bean-definition-overriding=true`" | `engineering-blog` | Spring Boot 2.1+ (bean override 기본 비활성) | bean override 활성화의 다른 side-effect (다른 bean 충돌 디버깅 비용) 는 본 인용 범위 밖 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `VSOUM-TX-C1` ~ `C4`: TransactionInterceptor 확장의 구조, Try 모나드 통합 동기, aopalliance 인터페이스, bean override 설정 요구사항
- **이 자료가 증명하지 않는 것**:
  - 이 패턴이 산업계 표준 / 권장 패턴이라는 주장 (`engineering-blog` 수준 — 개인 GitHub repo)
  - prod 환경에서의 안정성 또는 성능 측정값 (README 에 수치 없음)
  - Spring 마이너 버전 업그레이드 시 내부 API 변화에 대한 호환성 보장
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - ca-tmpl 이 functional error 타입 (Try/Either) 을 사용하는지 — 그렇지 않으면 본 패턴의 핵심 동기 (`VSOUM-TX-C2`) 가 부합하지 않음
  - `spring.main.allow-bean-definition-overriding=true` 의 부수 효과가 ca-tmpl 의 다른 bean 정의와 충돌하지 않는지

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- 적용 시나리오: 이미 `@Transactional` 을 광범위하게 쓰는 코드베이스에 functional error 핸들링(Try/Either) 을 도입하고 싶을 때.
- 장점:
  - 기존 Spring TX 인프라(PlatformTransactionManager, propagation) 그대로 활용.
  - rollback rule 을 `Either.Left` / `Try.Failure` 같은 데이터로 표현 → throw 남용 감소.
- 단점:
  - application 코드는 여전히 Spring annotation 에 노출.
  - bean override 활성화 → 부작용 디버깅 비용.
  - 라이브러리 업그레이드 시 `TransactionInterceptor` 내부 변화로 깨질 위험.
- ca-tmpl(TransactionPort) 와의 차이: 본 repo 는 "Spring TX 를 더 강하게 활용", ca-tmpl 은 "Spring TX 를 숨김". 같은 'AOP 활용 트랜잭션' 카테고리지만 dependency 방향이 정반대.
- testability 영향: 낮음 — Spring context 필수.
- code 복잡도 영향: 높음.

## Related / 관련

- 같은 주제 다른 raw:
  - [[raw/company-tech-blogs/hexagonal-reflectoring-transactional-placement]] (baseline `@Transactional` direct)
  - [[raw/company-tech-blogs/transaction-port-clean-ddd-spring-medium]] (TransactionPort 대안)
  - [[raw/company-tech-blogs/woowahan-hexagonal-multimodule]] (multi-module 보완)
- 인용하는 branch:
  - [[raw/branch-notes/feature-application-port-usecase-contract]]
  - [[raw/branch-notes/feature-transaction-concurrency-contract]]
- 인용하는 project:
  - [[raw/project-notes/ca-skeleton-operational-contract]] (§14, §5)
- 인용한 wiki 요약: (미작성)
- 대안 그룹: **Topic 2 — Transaction Boundary** (대안 5종: TransactionPort / @Transactional direct / TransactionTemplate / Functional monad / Custom AOP)
- 본 source 의 위치: 대안 5: Custom AOP / TransactionInterceptor 확장 (functional 통합)