종종 Spring Data 스택을 사용하다 보면 어떤 Entity Repoistory 던간에 자주 사용하는 기능이 나오기 마련이다 나의 경우 토이를 할때 Kotlin을 자주 사용하는데 ID에 의한 찾은 값의 반환타입이 Optional 보다는 nullable Entity 인게 편한 경우가 많았다 왜냐하면 Elvis Operator를 사용하는게 보다 간단하다고 생각했기 때문이다 val notNullObject = nullableObject ?: throw RuntimeException("null이 될 수 없습니다.") 이때 사용하면 좋은 심플한 트릭이다 Spring Data Repository 확장하기 확장할 Repository에서 구현하고자 하는 메서드만 기술한다 interface ExtendedCrudR..

코드는 이곳에 ! https://github.com/progress0407/jvm-tools/tree/main/redis 과거에 맡았던 도메인 중에 동일 요청건에 대한 중복 결제 요청을 막아야할 일이 있었다 (자세히 기술할 수 없다!) 그때 사용했던 방식이다 과거에 최범균님의 DDD에서 본 방법인데, 이름은 오프라인 선점 잠금으로 알고 있다 마침 사내에서 Redis를 사용했고 락을 짧은 시간 동안 유지 + 분산 환경임을 고려하여 Redis를 사용했다 세간에 알려진 오프라인 선점 락과는 다소 다른 것은... 시간 순서에 따른 락을 선점 -> 해제는 아니었다 즉 아래와 같은 상황이 아니었다 API 1 접근: Lock 획득 API2 접근: Lock 방출 정확히는 아래와 같은 상황이다 API 1에 동시 접근 가..

소스 코드는 아래에 있습니다! https://github.com/progress0407/E-Commerce-with-MSA-and-DDD 종종 멀티모듈 환경에서 테스트를 작성할때 이미 작성한 Test Fixture를 공유하고 싶을때가 있다 처음에는 아래처럼 단순히 testImplementation를 붙이면 공유가 가능하다고 생각했다 그렇게 해서는 되지가 않았다... 즉 위처럼 하면 안된다 이런 경우 test-fixture라는 plugin을 추가해서 해결할 수 있다 아래처럼 사용하면 된다 plugins { id 'java-test-fixtures' } 나 같은 경우 common/general이 test-fixture의 기능까지 함께 담당한다 그리고 해당 모듈이 가져야할 dependecny는 testFixt..

발음 때문인지 난 코틀린하면 코뿔소가 생각났다... 블로그를 많이 못해서 예전에 github 블로그에 기술한 것을 다시 정리 겸 가져 왔다 https://progress0407.github.io/backend/2023/02/18/%EC%BD%94%ED%8B%80%EB%A6%B0%EA%B3%BC_%EC%9D%BC%EA%B8%89%EC%BB%AC%EB%A0%89%EC%85%98.html 위와 같이 의문형으로 적은 것은 First-Class Collection을 창안한 사람의 생각을 정확히 알지는 못하기 때문이다 그렇지만 기억에 따르면 동욱님의 글을 보면서 파악한 것은 일급컬렉션은 아래의 정의를 따른다 - "List of 객체"를 감싼 행동을 정의할 수 있는 새로운 클래스 단순하게 말해 아래와 같은 것이 일급..

주의 이 글은 매우 김... YAGNI 아직 필요하지 않은 것에 대해 섣불리 구현을 해서는 아니된다는 뜻이다 난 이 원칙을... 멀티모듈 설계를 하면서 뼈저리 느낀 것 같다... 멀티 모듈이 가져다 주는 이점이 무엇인가? 이에 대해 생각하지 않고 먼저 모듈화하면 큰 이득 없이 시스템의 복잡도가 가파르게 올라가는 것을 느꼈다... 개인적으로... 아키텍처의 철학을 투영하기 위한 모듈화는 좋은 예시는 아니라고 생각해요 위 얘기는 내가 곧잘 보는 개발자가 안 좋은 모듈링에 대해 언급한 내용이다 좋은 모듈링이란 제약이 반드시 필요한 곳에 거는 것... 이라고 하였다 자세히는 언급할 수 없으나... 내가 재직하던 회사 중 한 곳의 어떤 프로젝트가 Layer 기준으로 모듈화가 되어 있었다 (아래 예시는 정확하지 않..

저번 글이 너무도 MSA에 대한 단점을 기술해서 장점 또한 분명히 있다는 것을 적기 위해 작성했다 (하하..) 아래는 실제로 MSA 환경에서 일하면서 느꼈던 장점을 적어보았다 독립적인 작업의 용이함 팀원과 같이 작업을 하다보면 항상 출근 직후 하는 한 가지 루틴이 있다 바로 개발 브랜치를 다운 후 작업 중인 브랜치와 싱크를 맞추는 것이다 - git pull origin dev - git checkout feat/my-working-branch - git merge dev 저게 별거 아닌 것 같아도 은근 번거로울 때가 많다 작업 중에 긴급하게 배포해야 하는 경우 - main 브랜치 이동 - pull & sync - hot-fix 브랜치 따기 - 버그 수정 - 확인후 배포 - main 브랜치 병합 - dev..

이 글은 마이크로 서비스 아키텍처에 대해 굉장히 주관적인 생각을 담고 있습니다 혹시나 불편하실 수 있다는 점 말씀드립니다... MSA를 하는 회사에 처음 들어가게 되었다... 회사에서 프로젝트를 보기 전엔 회사 아키텍처가 MSA란 것을 알지 못했다 공고엔 Spring Cloud라고 적혀있었지만, 특정 기술로 구성된 서버만 별도로 분리하고 그 외의 백엔드 서버는 모놀리식으로 구성되어 있다고 생각했다 큰 규모의 회사도 아니었고 그런 비용이 높은 설계를 굳이 채택할 필요가 없었다는 생각이 있었던 것 같다 그 덕분에 MSA에 대해 직접적인 경험을 할 수 있었다 사실 난 MSA에 관해 아주 많은 관심이 있던 사람 중 한 명이다 패션을 좋아하면 올해에 무슨 색이 시그니처인지 관심이 가는 것 처럼, 나 또한 22~2..

최근에 회사에 n단계 depth에 걸친 gradle이 있어서 여러 고민에 있다 아래에 예시로 둔 프로젝트가 있다 이 상황을 가정해서 한 번 진행하고자 한다 https://github.com/progress0407/multi-module-gradle-project GitHub - progress0407/multi-module-gradle-project: 멀티 모듈 프로젝트 연구 및 연습용 리포지토리 멀티 모듈 프로젝트 연구 및 연습용 리포지토리. Contribute to progress0407/multi-module-gradle-project development by creating an account on GitHub. github.com task: 하나의 빌드 작업 plugin: task들이 묶여서 ..

@Transcational 어노테이션에는 정말정말 매우 많은 기능이 있다 - 선언만으로 트랜잭션 보장 - DB 접근 계층 추상화 - 리소스 동기화 (쓰레드별 트랜잭션 관리) - 격리레벨 조정 - 전파레벨 설정 - 롤백 에외 설정 (특정 예외에 대해선 롤백하지 않는다) - readOnly + JPA사용시 약간의 성능 향상 (스냅샷 저장 X) 원리 이 마법을 어떻게 스프링은 이루어냈을까? AOP로 이것을 해낸다 사실 이 하나만으로 해낼 수는 없고 AOP와 IoC와 빈 후처리기(Bean Post Processor), 프록시가 이것을 해낸다 우선 스프링은 메서드 혹은 클래스 레벨에 @Transactional 어노테이션이 있는 클래스에 대해 CGLIB이란 라이브러리를 통해서 동적으로 생성한 Proxy객체를 생성하..

정합성 보장 WAS 여러대에서 정합성 보장 쓰기 DB가 여러대에서 정합성 보장 실행 속도 (실험) 작업 순서 처리 보장 동시성 고려 X X X X 1m 1s X synchronized X X X 4m 56s O 비관적 락 O O X 4m 32s O 낙관적 락 O O (#1) X 1m 5s X Redisson 락 O O O 4m 44s O #1 : 해줄 것으로 생각됨 동시성 고려를 하지 않은 경우 아래 이미지처럼 기대 예약 개수인 250개 보다 많은 366건이 예약됨을 알 수 있다 동시성 처리를 위해 synchronized를 사용한 경우 @Transactional synchronized public long bookPerformance(...) { //공연 예매 로직 } synchronized 위치가 저기..

전에 작성한 글이 길어져서, 포스팅을 분리했다 동작 흐름 ArgumentResolver는 아래와 같은 순서로 호출된다 Handler의 각 Parameter 리스트 순회한다 Argument Resolver 리스트를 순회하면서 1번의 Parameter의 타입에 일치하는 것을 찾는다 즉 O(N^2)이다 InvocableHandlerMethod 를 보도록 하자 (HandlerMethod의 자손) 먼저 파리미터들 목록을 가져온다 그 후 arguemntResolver들의 목록을 순회한다 언제 ModelAttributeMethodProcessor를 거치는가 결론: 커스텀 클래스인 모든 경우. (단, 커스텀 클래스에 대응하는 ArgumentResolver가 없는 경우) 먼저, 들어가기전에 간단히 알고 넘어갈 게 있다 ..

결론: ArguemntResolver를 WebMvcConfigurer에 등록하지 않음 이글을 쓰는 이유는 MVC에 대한 이해도가 다소 높아진 게기가 되어서 작성했다 알게 된 바에 의하면 웹 요청이 있으면 Dispatcher Servlet -> Interceptor 목록 순회 -> Handler Adapter -> ArgumentResolver -> Handler (Controller 위와 같은 순서로 진행이 된다 조금 더 상세히 얘기하면 Dispatcher Servlet 를 거친 후 해당 요청 URL에 대한 Interceptor 목록을 순회한 후 Handler Adapter 목록을 조회 (대부분의 경우 RequetMappingHandlerAdapter)후 이동할 Handler에 대한 Argument목록 ..