Backgroudhttps://se-mumu.tistory.com/27 [스프링 핵심원리 - 고급편] (복습) 예제 프로젝트 로그 추적기Background현재 마이브러리에는 User Service, Book Service에 AOP 기반으로 '어떤 사용자(uuid)가 어떤 API 요청을 보냈는지' 로그를 남기고 있다. (내가 개발 안함🙃)AOP가 이러한(로깅, 트랜잭션 등) 공통 로se-mumu.tistory.com로그 추적기의 TraceId를 파라미터로 넘기는 방법이 넘 비효율적이다!다른 방법이 없을까? OverviewLogTrace 인터페이스향후 여러가지 방법으로 구현해볼 수 있도록, 다음 세 가지 기능을 가진 인터페이스를 만들어보자요청 로그 기록응답 로그 기록예외 발생 시 로그 기록public in..
Background현재 마이브러리에는 User Service, Book Service에 AOP 기반으로 '어떤 사용자(uuid)가 어떤 API 요청을 보냈는지' 로그를 남기고 있다. (내가 개발 안함🙃)AOP가 이러한(로깅, 트랜잭션 등) 공통 로직을 묶어서 핵심 로직과 분리하고, 모듈화 하여 재사용성을 높일 수 있는 개념으로 알고 있었다.근데 구체적인 구현 방법과 동작 원리가 궁금해서 [스프링 핵심원리 - 고급편] 강의를 수강하기로 했다.AOP에 대해 깊이 있게 학습하고, 내가 작성한 마이브러리 코드에 적용하는 것을 목표로 설정했다.24년 2월부터 4월까지 틈틈이 강의를 들었는데, 이제서야 스프링 AOP에 대해 들을 참이다.😅그 전에, 강의를 수강하면서 배우고 실습했던 내용들을 복습하면 좋을 것 같..
우아한테크코스 [10분 테코톡] 말랑의 스프링 이벤트를 참고해 작성했습니다. 요구 사항 회원가입을 하면 쿠폰을 제공한다 구현 결과 멤버 서비스 signUp(MemberInfo): Member 영속화 후 쿠폰 서비스의 give를 호출해 멤버에게 쿠폰 제공 쿠폰 서비스 give(Member): Member가 포함된 생성자를 통해 Coupon 생성 후 영속화 문제 발생 멤버 서비스가 쿠폰 서비스를 직접 호출 (멤버->쿠폰 의존성) 쿠폰 서비스가 멤버 객체를 포함 (쿠폰->멤버 의존성) ➡️ 의존성 사이클 발생 해결 방법 인터페이스를 통한 의존성 역전 허브 부르기 이벤트 이벤트로 해결하기 멤버 서비스에서 쿠폰 서비스를 직접 호출하지 않고 회원 가입 했다는 이벤트 발행 해당 이벤트를 받으면 쿠폰이 발생 로직 처리..
Persistence Layer vs Business Layer Persistence Layer Data Access의 역할 비즈니스 가공 로직이 포함되어서는 안됨 Data에 대한 CRUD에만 집중한 레이어 Business Layer 비즈니스 로직을 구현하는 역할 Persistence Layer화의 상호작용(Data를 읽고 쓰는 행위)을 통해 비즈니스 로직을 전개시킴 트랜잭션을 보장해야 함 요구사항 상품 번호 리스트를 받아 주문 생성하기 주문은 주문 상태, 주문 등록 시간을 가진다 주문의 총 금액을 계산할 수 있어야 한다 TDD로 OrderService 테스트하기 1. RED OrderService 클래스 생성 @Service public class OrderService { public OrderRes..
레이어드 아키텍처와 테스트 왜 레이어를 분리하는가? 관심사의 분리 사용자의 요청이 왔을 때 각 레이어별로 역할을 주자 책임을 나누어서 유지보수 하기 용이하게 구성하자 객체들의 협력에 따라 단위 테스트만으로 커버하기 어려운 상황이 발생? 통합 테스트 여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트 일반적으로 작은 범위의 단위 테스트만으로는 기능 전체의 신뢰성을 보장할 수 없음 풍부한 단위 테스트 & 큰 기능 단위를 검증하는 통합 테스트 권장 Spring/JPA 훑어보기 라이브러리 vs 프레임워크 라이브러리 사용: 내 코드가 주체가 되며, 필요한 기능을 외부(라이브러리)에서 가져옴 프레임워크 사용: 이미 갖춰진(동작할 수 있는) 환경들이 구성되어 있고 내 코드가 수동적으로 프레임 내에서 동작함 Spr..
테스트는 [문서] 다 왜 문서일까? 테스트 코드 문서는 프로덕션의 기능을 부연 설명한다 다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완한다 어느 한 사람이 과거에 경험했던 고민의 결과물을 팀 차원으로 승격시켜서, 모두의 자산으로 공유할 수 있다 우리는 항상 팀으로 일한다는 것을 기억하자 DisplayName을 섬세하게 음료 1개 추가 테스트 ➡️ 음료를 1개 추가할 수 있다. ➡️ 음료를 1개 추가하면 주문 목록에 담긴다. 명사의 나열보다 문장으로 짓기 ~테스트로 짓는 것을 지양하기 테스트 행위에 대한 결과까지 기술하기 특정 시간 이전에 주문을 생성하면 실패한다. ➡️ 영업 시작 시간 이전에는 주문을 생성할 수 없다. 도메인 용어를 사용하여 한층 추상화된 내용을 담기 메서드 자체..
