지금까지 내가 헥사고날 아키텍처를 설계해 보며 배운 점을 정리해 봤다.📌 서론지금까지 3번 정도 헥사고날 아키텍처를 적용시켜서 프로젝트를 만들어봤다. 첫 번째 설계에서는 왜 port 같은 것을 사용해서 이렇게 복잡하고 어렵게 설계하는 거지? 이런 생각이 많이 들었다. 원리를 이해하지 못하고 단순히 이게 좋다니까 해봐야겠다! 이런 생각을 하면서 개발을 진행했었던 것 같다. 관련된 자료를 열심히 찾아보기도 했지만 사실 제대로 알지 못하고 개발을 진행했다.이렇게 원리를 잘 모르고 일단 개발해 보자는 마인드로 개발을 진행한 후 다시 한번 돌아보니 도메인 내부에 비즈니스 로직을 넣어두는 중요성을 놓치고 있었다. 그래서 서비스의 로직이 엄청 커지고 패키지도 많고 클래스도 많다 보니 오히려 이전과 큰 차이는 없으면..

SpringBoot3.3.1에 gRPC를 적용시켜 보자📌 서론개인적인 공부를 하면서 MSA 프로젝트를 구성할 때 유저(Client)의 기본적인 요청에 대해서 먼저 http로 받아서 처리하고 만약 서버 간 소통이 필요하다면 그때는 gRPC를 사용하도록 하기 위해 gRPC를 도입해보고자 했다. 아무것도 모르는 상태에서 공부를 시작했고 일단 도입해 보면서 발전시켜 가자는 목표로 코드에 1차 적용을 시켰다. 막상 적용시켜보니 버전에 대해서 이슈가 조금 있어서 생각보다 오래 걸렸지만 잘 동작하는 것을 보니 매우 뿌듯했다.혹시나 gRPC를 도입하고자 하는 분들을 위해 적용방법을 남기고 가능하면 조금 더 좋은 방법이 있다면 도움을 받고싶다.코드는 아래 Repo에 넣어두었습니다! GitHub - wlsdks/grpc..

예외가 발생하면 stackTrace는 어떻게 생성될까? 📌 서론 RuntimeException이 발생했을 때 (우리가 주로 커스텀 예외를 만들 때도 RuntimeException을 던진다.) 우리 개발자들은 예외가 발생하면 로그창에서 stackTrace 로그 내용을 분석하며 쉽게 오류사항을 찾아내곤 한다. 스프링은 발생하는 예외를 어떻게 처리하고 stackTrace에 그 내용을 남기는 걸까? 이번 포스트에서는 직접 RuntimeException 예외를 발생시키고 이 예외를 처리하는 코드를 따라가 보며 최종적으로 stackTrace를 만들어주는 코드를 분석해 보도록 하자. 이렇게 코드 분석을 따라가다 보면 알게 되는 점은 다음과 같을 것이다. 1. RuntimeException은 어떻게 처리되는가 (예외처..

@ModelAttribute에서 데이터 바인딩을 위해서 꼭 필요한 메서드가 존재한다. 📌 서론 컨트롤러에서 매게 변수로 dto객체를 받을 때 발생하는 바인딩 오류는 정말 간단하게 해결되지만 자주 발생하는 오류이기도 하다. 그만큼 바인딩에 대해서는 신경 쓰지 않고 알아서 적용되겠지?라는 생각을 가지고 어노테이션을 사용하게 되기 때문인데 수많은 api를 만들어 보게 되지만 바인딩도 @RequestBody인지 @ModelAttribute인지에 따라 그 방식이 다르다. 이번에는 @ModelAttribute를 사용했을 때 나의 실수로 인해 바인딩에 실패했던 내용을 소개하고자 한다. 1. 오류가 발생한 상황 오류가 발생한 코드 분석 아래의 API에 요청을 보냈을 때 바인딩 오류가 발생했다. /** * 마이페이지 수..

validation을 사용하여 dto 코드를 작성하고 통합테스트를 진행하던 도중 처음 겪는 문제에 직면했다. 📌 서론 통합테스트에서 "사용자가 잘못된 값을 입력해서 보내면 적절한 예외가 발생한다." 이런 bad 케이스 테스트를 작성하고 실행했다. 이때 예외가 발생해야 테스트가 성공하는데 내가 작성한 테스트에서는 예외가 발생하지 않았다. 그래서 나는 가장 먼저 사용자로부터 데이터를 받아오는 dto객체를 살펴봤다. 나는 dto 객체 내부에 Integer타입을 받는 변수를 선언해 주고 spring-validation의 기능을 적용하여 @Min(0)을 적어줬는데 이렇게 해주면 음수(-) 값이 들어왔을 때 검증에 의해 예외가 발생한다. 이렇게 열심히 세팅한 후 테스트를 진행했다. 그런데 보기 좋게 테스트에 실패했..

톰캣과 스프링의 웹 요청 처리방법을 이해해 보자 📌 서론 스프링은 복잡한 저수준의 소켓 통신과 스트림 처리를 추상화하여, 개발자가 고수준의 비즈니스 로직에 집중할 수 있도록 설계되었다. 이번 포스트를 통해 스프링 프레임워크와 서블릿 컨테이너(예: Tomcat)가 HTTP 요청을 어떻게 처리하는지, 그리고 이 과정에서 각각의 역할이 무엇인지 상세히 살펴보자 1. 스프링의 http 요청과 관련된 용어 이해하기 서블릿 컨테이너 스프링 애플리케이션은 일반적으로 서블릿 컨테이너(예: Tomcat, Jetty) 내에서 실행된다. 이러한 컨테이너는 저수준의 네트워크 통신을 처리하고, HTTP 요청을 서블릿 API로 변환해 애플리케이션에 전달하는 역할을 한다. DispatcherServlet DispatcherServ..

이번에는 스프링 이벤트 리스너의 내부 동작 테스트 코드를 통해 검증해 보자 📌 서론 이벤트 기반 아키텍처로 백엔드 개발을 진행할 때 이벤트 리스너가 호출되면 내부에서 작성했던 코드가 제대로 동작하는지 테스트하는 것은 애플리케이션의 정확성을 보장하는 데 굉장히 중요하다. 특히, 이벤트 리스너가 이벤트를 받아서 내부에서 어떤 처리를 하는지 확인하는 것이 중요하다. 이번 포스트에서는 RecipeCreationEvent 이벤트가 발행될 때 saveIngredientsIntoMongo 메서드의 내부에서 동작하는 메서드를 검증해 보자 저번 포스트에 이어지는 내용이니 보고 오시는 것을 추천합니다.👇🏻👇🏻 [Spring] 테스트 코드: @MockBean으로 @EventListener 검증하기 테스트 코드를 통해 스프링..

스프링에 적용된 싱글톤 패턴에 대해서 간단히 알아보자 1. 싱글톤 패턴의 구조 이해하기 1-1. 스프링 컨테이너 이해하기 스프링 컨테이너는 ApplicationContext를 통해 정의된다. 이 컨테이너는 IoC(Inversion of Control) 또는 DI(Dependency Injection) 컨테이너로도 알려져 있다. 주요 역할은 애플리케이션 내의 빈(Bean)들을 인스턴스화, 구성, 관리하는 것이다. 이 과정을 통해 개발자는 객체의 생성과 생명주기에 대해 걱정할 필요 없이 비즈니스 로직에 집중할 수 있다. 1-2. IoC 컨테이너 (스프링 컨테이너)의 중요성 IoC 컨테이너는 객체의 생성과 의존성 주입을 담당한다. 이는 객체 간의 의존성을 느슨하게 만들어, 코드의 재사용성과 테스트 용이성을 향..