Aspect로 JPA Auditing 구현하기

Auditing 테이블의 데이터를 생성하거나 변경했을 때, 우리는 생성자와 변경자를 기록합니다.이를 위해 보통 createdBy나 creator와 같은 파라미터를 추가해서 요청 데이터를 만들죠. 그러나 요청 파라미터명은 언제나 정해져있고, (예를 들어 어디는 createdBy를 사용하고 어디는 madeBy를 사용하지 않습니다.)보통 그 값이 동일하게 처리되기 때문에 (예를 들어 어디는 생성자가 A인데 어디는 B이고 하지 않습니다.)매번 핸들러 메소드로부터 서비스 로직까지 중복해서 파라미터를 전달하는 게 불편할 수 있습니다.특히 전달 과정에서 값이 변경될 우려도 있습니다. Spring JPA Auditing은 엔티티 클래스 내에서 어노테이션을 통해 알아서 값을 주입해줍니다.그래서 더이상 개발자가 서비스 ..

Hexagonal Architecture 누군가 와서 가장 좋아하는 아키텍쳐를 말해달라고 하면 필자는 Hexagonal Architecture을 든다.사실 필자는 좋은 설계를 넘어서 아름다운 설계라고 자신할 정도로 좋아한다.쉽게 설명하면, 각 컴포넌트들은 서로 결합이 없고, 어댑터라는 특정 포트(port)를 통해서만 데이터 교환이 가능한 설계다.The hexagonal architecture divides a system into several loosely-coupled interchangeable components, such as the application core, the database, the user interface, test scripts and interfaces with other ..

Blob 대다수의 개발자는 - 개발을 시작하는 경우, 일단 구현을 어떻게 한 번에 할 지에 초점을 맞춘다.특히 코딩 테스트로 단련된 사람일 수록 더욱이 그런데, 쉽게 덩어리 코드를 만든다.믿지 못하겠다면, 아래 테스트를 풀어보고 다른 사람의 풀이를 한 번 보자. 다 죄다 solution 함수만 만들었을 것이다.https://school.programmers.co.kr/learn/courses/30/lessons/389480# 최근에 개인적으로 재밌는 우주 시뮬레이션 프로젝트를 만들면서,필자는 천문학자가 아니기에 AI에게 행성 간 중력을 계산해서 새로운 위치 좌표값을 만드는 코드를 부탁했었다. 그리고 이와 같은 덩어리 코드를 마주쳤다.더보기import type Planet from "./models/pl..

Spring Web Framework Spring 웹 프레임워크는 크게 MVC와 WebFlux로 나눌 수 있습니다.MVCWebFluxBlockingPrimitive, CollectionThread per RequestServlet APINon-BlockingMono, FluxEvent Loop ThreadsReactive Stream APIDispatcherServletDispatcherHandler Spring MVC는 Tomcat, Jetty, Undertow 등 서블릿 기반의 웹서버에서 동작합니다.하나의 요청에 하나의 스레드를 배정해주는 모델인데, 사실 이건 꽤나 부담스러운 작업입니다.application properties 문서를 참고해보면, 기본 스레드 개수를 찾을 수 있습니다.server.j..

With MVC Spring MVC는 하나의 요청에 대한 하나의 스레드를 사용하는 블로킹(blocking) 방식 모델로,트랜잭션이나 비즈니스 로직에 알맞기 때문에 - 일반적으로 사용됩니다. 사실 스트리밍에 특화된 프레임워크로는 Spring WebFlux가 있지만, 별도의 서버 비용을 아끼고 싶거나 서버 분리에 대한 어려움을 가지고 있다면 Spring MVC에 있는 스트리밍 기술을 사용하는 것도 나쁘지 않아 이 글을 쓰게 되었습니다. Streaming 먼저 스트리밍을 사용하지 않는 예시를 살펴보겠습니다.아래 메소드는 delayCount (딜레이 수), delayMillis (딜레이 시 지연 밀리초)를 파라미터로 받아 수행하는 예시입니다.(지연에 대한 건 - 트랜잭션이라고 생각해도 좋고 특정 동기 작업..

Useless Coding 쉬운 길과 돌아가는 길이 있을 때, 우리는 당연히 쉬운 길을 선택한다.특히 저 너머에 있는 목표가 눈에 선하게 보인다면, 신나서 미친듯이 뛰어오른다. 뭐, 필자도 마찬가지로 처음 개발을 시작할 때는 마냥 신나서 만들고 싶은 게 있으면 무작정 코드를 작성했었다.어찌되었든 빠르게 결과를 보는 게 좋았고, 또 그 자체가 즐거웠기 때문이다. 그러나 그 코드는 절대 다시 사용할 수 없다.다른 걸 만드려면 복사&붙여넣기로 전체 코드를 가져온다음, 특정 부분을 고쳐야 되는데,그 노가다란 참으로 지루하고 오래걸리기 때문에 쉽지 않다. 실무에서도 이렇게 재밌게(?) 만든 코드를 심심치 않게 목격했었다.다들 쉽고 빠른 길의 유혹은 떨쳐버리지 못하는 것인데 -그러나 그럴수록 그 코드는 점점 심해..