ecsimsw

도메인 이벤트로 의존성 분리? 우아한테크코스 지원 플랫폼 개발을 하면서 제이슨한테 배운 개념이다. 그 당시에는 '오 멋진걸~, 이렇게도 할 수 있구나 🤩' 정도였도로 지나쳤었다. 패키지간의 의존, 리팩토링을 위한 분리를 고민하기 시작하면서 이제는 좀 더 와닿아서 이렇게 대박 기술인 양 정리하게 되었다. 문제와 요구 사항 커머스 서버를 만드는 프로젝트를 발전시키는 중이었다. 기존에는 없었던 명세였는데, 각 상품별 주문 횟수를 기록할 수 있다는 요구 사항이 추가되었다. 1. 사용자가 주문(Order)을 생성하게 되면, 그 장바구니에 포함된 각 제품(Product)에 orderedCount를 증가시킨다. 이 이전까지는 OrderService는 Product 관련 도메인을 분리해둔 상황이었다. 이번 요구 사항을..

외부 디렉토리 동적 파일 참조 스프링부트에서 파일을 응답하는 법을 정리하려고 한다. 다만 보통 resouces/static에 넣어 사용하는 정적 컨텐츠가 아닌, 실행 도중 동적으로 생성하거나, 관리하는 파일을 다루는 방법을 고민해보았다. 요구 사항 1. 사용자가 실행 도중 업로드한 파일을 저장한다. 2. 저장된 파일의 물리적인 경로를 숨기면서 요청 -> 응답할 수 있도록 하고자 한다. 3. 즉 실제 파일 물리 경로인 card-photos/** 과 달리, 클라이언트의 요청은 /images/cards/** 처럼 명확한 path로 요청할 수 있도록 하고자 한다 방법 위 같은 요구 사항은 다음처럼 ResourceHandler를 사용하면 간단히 해결할 수 있다. 아래처럼 WebMvcConfigurer를 구현하고,..

기존 PR 방식에 지친다면?마틴파울러 블로그에 소개된 브랜치 전략을 소개하려고 한다. Rouan Wilsenach가 올해 9월 달에 작성한 따끈따끈한 글인데, 공감되기도 하면서도 필요한 팀들이 많을 것 같아 정리해본다. CI 정책이 확실하게 있고 팀원들이 어느 정도 경력이 있다면, 그리고 기존의 PR 방식이 늘어지고 의미 없다고 느껴본 적이 있는 사람이라면 한 번쯤 읽어보면 좋을 것 같다.  Ship / Show / AskShip/Show/Ask is a branching strategy that helps teams wait less and ship more, without losing out on feedback.martinfowler.com 간단한 정리Rouan Wilsenach가 제안하는 이유와 ..

클릭 위치가 부채꼴 안에 포함되어 있는지 알고 싶어요! 옆 회의실에서 '프롤로그'팀이 수학 문제 푸는 거를 보고 재밌어 보여 나도 참여해보았다. 라이브러리 없이 직접 확률에 따른 사잇각을 구하고 영역 클릭시 해당 내용을 확인할 수 있는 기능을 구현 중이었고, 사용자 클릭 이벤트가 주어졌을 때 그 좌표가 해당 영역에 포함되어 있는지 확인할 수 있는 로직이 필요했다. 1. 클릭 범위 확인 우선 클릭할 수 있는 범위가 맞는지를 확인했다. 아래 그림에서 빨간색으로 표시한 부분을 말한다. 간단히 작은 원보다 밖에 있고, 큰 원 안에 있는지를 확인하면 된다. 2. 각도 확인 이번에는 좌표가 A 영역 부채꼴 안에 포함되었는지를 확인할 것이다. 영역 시작 선을 a, 영역 끝 선을 b이라고 한다. x축과 a가 이루는 각..

좋아하는 것어렸을 때부터 문제를 해결하는 것을 좋아했다. 책장에는 추리 소설이나 퀴즈 책만 있었고, 장기, 체스가 세상에서 가장 재밌는 게임이었으며, 수학 문제를 푸는 희열에 중고등학교 때는 솔직히 수학만 했다. 풀이를 고민하고 딱 해결했을 때의 그 쾌감, 그리고 그걸로 주변 친구들에게 받던 인정이 그렇게 좋았던 것 같다. 다른 어느 때보다 재밌었다. 문제 푸는 것만큼이나 뭔가를 만드는 것을 좋아했다. 죄다 과학자나 대통령을 꿈꾸던 주변 친구들이 하나둘씩 현실적인 장래희망을 갖게 될 때 까지도 나는 발명가를 꿈꿨다. 매일 작은 수첩과 그 크기의 샤프를 들고 다녔던 기억이 난다. 갑자기 드는 생각을 기록하고 싶어서. 그 작은 샤프도 내가 만들었었다. 그리고 사람을 좋아한다. 그냥 사람들과 함께 하는게 너무..

스케줄러 정기적으로 실행해야 하는 테스크가 있을 수 있다. 일정 시간 간격으로 로직을 실행하거나, 일정 스케줄러는 그런 테스크를 처리하기에 유용하게 사용할 수 있다. 예를 들면 10초마다 한 번씩 혹은 매월 1일마다 한 번씩 지정한 로직을 수행하도록 하는 것이다. 이번 프로젝트에서 매일 한번씩 정산하는 로직을 수행해야 한다. 처음에는 아래처럼 단순히 요청 처리를 위한 스레드와 별도의 스레드를 생성하고 그 안에서 무한정 시간을 비교하는 로직을 수행하려 했으나, 스프링의 스케줄러를 사용하면 직접 스레드를 관리하지 않아도 되고, 시간 비교를 효율적으로 할 수 있을 것이라는 생각에 스프링 스케줄러를 사용하게 되었다. 스프링 프레임워크에서 Quartz 라이브러리를 사용할 수 있다. 스프링 프레임워크에서 기본적으로..

도입 배경 시작하기 앞서 기존의 배포 방식을 먼저 설명하려고 한다. 적용한 프로젝트의 배포 방식은 아래 그림처럼, 젠킨스가 프로젝트를 빌드, 전달하고 실행 스크립트에 의해 인스턴스 내부에서 실행하고 있다.   그렇게 빌드된 jar 파일을 실행하는 과정은 단순히 실행 중인 Application 프로세스를 종료하고, 새로 빌드된 Application을 띄우는 것이었는데, 이런 기존 방식에 두 가지 문제가 있었다. 기존 방식의 실행 스크립트 확인하기더보기#!/bin/bashecho "> now ing app pid find!"CURRENT_PID=$(pgrep -f back-end) # PID 구별 key로 back-end가 들어갔다. 본인 환경에 맞게 수정한다.echo "$CURRENT_PID"if [ ..

CloudWatch agent 로그 파일 지정과 이벤트 수집Spring application에서 발생하는 로그 파일을 확인하기 위해 매번 인스턴스에 직접 들어가서 파일을 확인하는 작업은 번거롭고, 위험하다. 가급적이면 개발자 개인이 배포 서버 인스턴스를 직접 건드는 작업을 피하고 싶었고, application에서 생성되는 로그 파일을 CloudWatch에 출력하고자 했다. 애플리케이션에서 생성된 파일을 CloudWatch에 출력하는 방법, 그리고 파일로 생성하지 않고 서버의 정보를 CloudWatch에 직접 뿌리는 방법을 공부해왔다. 전자의 경우에는 에러 파일을 그래도 출력하기 위함이었고, 후자의 경우에는 서버의 동작 여부를 확인하기 위함이었다.  해당 프로젝트내에선 사실상 에러 로깅 외의 로그가 없었고..