뚝딱 뚝딱 개발일기

프록시와 내부 호출 문제 (@Transactional self-invocation)

스프링에서 @Transactional을 사용하다 보면 내부 호출(self) 때문에 트랜잭션이 적용되지 않는 문제가 발생한다. "self-invocation does not lead to an actual transaction at runtime"(자기 자신 안에서 자기 자신의 트랜잭션 메서드를 호출하면 실제 트랜잭션이 동작하지 않는다)문제의 원인: Spring AOP의 프록시 방식Spring은 프록시 방식의 AOP를 사용한다. 이는 다음과 같은 특징이 있다.AOP를 적용하려면 항상 프록시를 통해서 대상 객체를 호출해야 한다.프록시에서 먼저 어드바이스를 호출하고, 이후에 대상 객체 호출프록시를 거치지 않고 대상 객체를 직접 호출하면 AOP가 적용되지 않음 정상적인 경우외부 호출 → 프록시 객체 → 어드바이..

패키지 구조 설계 package 구조hello.logindomainitemmemberloginwebitemmemberlogin도메인 = 화면, UI, 기술 인프라 등등의 영역은 제외한 시스템이 구현해야하는 핵심 비즈니스 업무 영역을 말함. 향후 web 을 다른 기술로 바꾸어도 도메인은 그대로 유지할 수 있어야 한다.이렇게 하려면 web 은 domain을 알고 있지만 domain 은 web 을 모르도록 설계해야한다. 이것을 web 은 domain을 의존하지만 domain 은 web 을 의존하지 않는다고 표현한다. 예를 들어 web 패키지를 모두 삭제해도 domain 에는 전혀 영향이 없도록 의존관계를 설계하는 것을 중요하다. 반대로 이야기하면 domain 은 web 을 참조하면 안된다.로그인 처리하기 - ..

# 1. target 디렉토리를 SVN 추적 대상에서 제거하되, 실제 파일은 삭제하지 않음 svn delete --keep-local target/ # 2. 현재 디렉토리에 svn:ignore 속성을 설정하여, target 디렉토리를 앞으로 무시하도록 지정 svn propset svn:ignore target . # 3. 위의 변경 사항(삭제 + 무시 속성 추가)을 커밋 svn commit -m "Ignore target directory" 확인 # 현재 디렉토리에 설정된 SVN 속성 목록을 조회 # (예: svn:ignore, svn:externals 등 설정 여부 확인 가능) svn proplist # 현재 디렉토리에 설정된 svn:ignore 속성의 실제 값을 확인 # 출력이 'target'이면, ..

외부 연동 방식 변경과 어댑터 패턴 적용최근 회사에서 외부 시스템과의 연동 방식이 변경되었다.기존에는 DB를 직접 조회해서 데이터를 받아오는 방식이었지만, 변경 이후에는 REST API를 통해 외부 데이터를 호출하도록 요구사항이 바뀌었다.이런 구조 변경은 일반적으로 기존 코드에 많은 영향을 줄 수 있다.하지만 나는 이 상황에서 기존 비즈니스 로직을 전혀 수정하지 않고도 외부 연동 방식만 바꿔치기할 수 있도록 어댑터 패턴(Adapter Pattern) 을 적용해보았다.어댑터 패턴이란?어댑터 패턴은 호환되지 않는 인터페이스를 가진 클래스를 함께 동작하게 해주는 구조 패턴이다. 기존 인터페이스를 클라이언트가 기대하는 형태로 변환해줌으로써, 서로 다른 클래스들이 함께 동작할 수 있도록 도와준다.실생활 예를 들면..

MySQL과 MongoDB는 데이터를 조작하는 방식에서 근본적인 차이를 보인다.MySQL 은 전통적인 SQL 쿼리 언어를 사용하는 반면, MongoDB는 API 호출 방식의 접근법을 취한다.이 글에서 실제 개발에서 자주 사용되는 쿼리를 비교하며 각각의 특징과 장단점을 살펴본다.1. 데이터 삽입 (INSERT)MySQL 방식INSERT INTO users(id, name, department) VALUES(1001, '김철수', '컴퓨터'); MongoDB 방식db.users.insertOne({ id: 1001, name: "김철수", department: "컴퓨터"}); 핵심 차이점MySQL : 구조화된 쿼리 언어전통적인 SQL 문법 사용테이블과 컬럼 구조가 명확히 정의됨INSERT, VALUES..

클래스를 안전하게 변경하기 위해서는 테스트 코드가 중요하다. 리팩토링이 무서운 당신에게: 테스트로 안전하게 코드 개선하기"이 코드를 건들리면 뭔가 망가질 것 같은데.." 혹시 이런 생각을 해본적이 있나요?리팩토링에 대한 두려움을 극복하고, 테스트를 통해 안전하게 코드를 개선하는 방법을 알아보자. 리펙토링, 왜 무서울까?리펙토링(Refactoring)은 프로그램의 기능은 그대로 유지하면서 이해하고 내부 구조만 개선하는 작업이다. 쉽게 말해:기능은 동일코드는 더 깔끔하고 이해하기 쉽게유지보수성 향상 그런데 왜 많은 개발자들이 리팩토링을 두려워할까?답은 간단하다. 내부 구조를 바꾸다 보니 버그가 생길 가능성이 높기 때문이다.리팩토링의 든든한 안전장치 : 테스트그렇다면 어떻게 안전하게 리팩토링 할 수 있을까..

자바 개발을 하다보면 비슷한 코드가 반복되거나, 코드 블럭을 파라미터처럼 전달하고 싶을 때가 있다.자바 8 에서 등장한 람다(Lambda)는 바로 이런 상황에서 빛을 발한다.이 글에서는 람다가 왜 필요한지, 그리고 어떻게 코드가 리펙토링 되는지를 예제를 통해 설명한다. 리팩토링의 핵심: 변하지 않는 것과 변하는 것을 분리하라 프로그래밍에서 중복을 제거하고, 좋은 코드를 유지하는 핵심은 변하는 부분과 변하지 않는 부분을 분리하는 것이다.변하지 않는 부분은 그대로 유지하고 변하는 부분을 어떻게 해결할 것 인가에 집중하면 된다. [1단계] 값 매개변수화 (Value Parameterization)리펙토링 전package lambda.start;public class Ex0Main { public stat..

스프링 부트를 사용하면 application.yml 또는 application.properties 파일에 설정값을 정의하고, 이를 코드에 주입받을 수 있다.이번 포스팅은 설정을 주입하는 주요 3가지 방법을 정리하고, 그 특징과 장단점을 비교한다. 외부 설정 사용 - Environment다음과 같은 외부 설정들은 스프링이 제공하는 Environment를 통해서 일관된 방식으로 조회할 수 있다. 외부 설정의 종류설정 데이터 (application.properties)OS 환경변수자바 시스템 속성커맨드 라인 옵션 인수다양한 외부 설정 읽기스프링은 Environment는 물론이고 Environment를 활용해서 더 편리하게 외부 설정을 읽는 방법들을 제공한다. 스프링이 지원하는 다양한 외부 설정 조회 방법En..

외부 설정이 필요한 이유애플리케이션을 개발하다 보면 운영 환경과 개발 환경이 서로 다른 설정값을 요구하는 경우가 많다.개발 환경: 개발 서버, 개발 DB 사용운영 환경: 운영 서버, 운영 DB 사용각각의 환경에 따라서 서로 다른 설정값이 존재한다.예를 들어 DB 접속 URL만 해도 환경에 따라 다를 수 있다. 개발: dev.db.com운영: prod.db.com 잘못된 접근 방식: 환경별로 빌드 결과물을 나누는 것초기에는각각의 환경에 맞게 애플리케이션을 빌드하는 것이다.개발 환경용 app-dev.jar, 운영 환경용 app-prod.jar 등 환경마다 서로 다른 빌드 결과물 생성환경에 따라 변하는 설정값을 내부에 포함개발 환경에는 dev.db.com 이 필요하므로 이 값을 애플리케이션 코드에 넣은 다음에..

https://newfangled.tistory.com/164 값 객체(Value Object)를 사용해야 할 때 – Game 클래스 리팩터링 예시작은 클래스, 단순한 구조, 더 명확한 의도 표현들어가며작고 단순한 클래스를 만들기 위해 값 객체(Value Object) 를 활용할 수 있다.이번 글에서는 "게임 매출 관리 애플리케이션" 을 예시로,값 객newfangled.tistory.com 클래스를 분리하는 두 가지 방법이 있다.값 객체 (지난 포스팅 참고)단일 책임 원칙단일 책임 원칙을 사용해 클래스를 분리해보자. 예제 - 반복 일정 관리반복적인 일정을 관리하는 애플리케이션한달에 한번씩 반복되는 일정을 등록할 수 있다. 예를 들어, 월간 회의를 매달 두 번째 주 월요일 오후 2시부터 1시간까지 반복일..