안녕하세요. 스프링 백엔드 개발자 stark입니다!백엔드 업무를 하면서 개발자들끼리 코드 구조에 대한 대화를 하다 보면 의존성과 결합도라는 용어를 정말 많이 사용합니다. 개발에서 얘기하는 의존성 그리고 결합도는 뭘 의미하는 걸까요? 이 궁금증을 해소하기 위해 이번 포스팅에서는 의존성과 결합도에 대해 가볍게 알아보고 의존성 주입(DI: Dependency Injection)을 통해 어떻게  높은 의존성을 풀어나가는지 알아봅시다.  의존성이란 무엇인가?의존성은 쉽게 말해 한 클래스가 다른 클래스의 기능에 의존한다는 것을 의미합니다. 예를 들어, OrderService 클래스가 주문 처리를 위해 PaymentService의 기능(메서드)을 필요로 한다면, OrderService 클래스는 PaymentServi..

안녕하세요. 트랜잭션이 흥미로운 개발자 stark입니다!최근 트랜잭션에 대해서 공부하다 보니 좀 더 궁금한 것들이 있어서 포스팅을 작성하게 되었습니다. 이번 포스팅에서는 같은 클래스 내에서 메서드를 호출할 때 프록시 기반 트랜잭션이 동작하지 않는 문제를 다뤄봤습니다. Spring에서 트랜잭션 관리는 데이터의 무결성을 보장하는 중요한 기법입니다. 잘못된 트랜잭션 관리로 인해 발생할 수 있는 데이터 손실이나 오류를 방지하기 위해서는 트랜잭션의 동작 방식을 제대로 이해해야 합니다. 특히 같은 클래스 내에서의 메서드 호출 시 트랜잭션이 의도한 대로 동작하지 않는 경우가 있어 이를 이해하고 적절히 대응하는 것이 중요합니다.  프록시 기반 트랜잭션이란?Spring에서 트랜잭션 관리를 위해 @Transactional..

안녕하세요. 개발자 stark입니다! 오늘은 재미있는 주제를 가지고 왔습니다. 바로 인기 아티스트인 지드래곤의 power 콘서트 티켓팅 시스템을 구현하면서 겪을 수 있는 동시성 문제와 그 해결 방법에 대해 이야기해보려고 합니다. (실제로 존재하는 콘서트는 아니며 이런 콘서트가 있다고 상황만 가정해 봤습니다.) 아마 많은 분들이 티켓팅에 도전해 보신 경험이 있으실 텐데요. 인기 공연은 오픈과 동시에 수만 명이 접속합니다. 이런 상황에서 시스템이 제대로 동작하지 않으면 어떤 문제가 발생할까요? 예를 들어, 지드래곤의 power 콘서트는 굉장히 특별한 콘서트라 단 100석만 예약이 가능하다고 가정해 보겠습니다. 이 콘서트를 예매하기 위해 만 명의 사용자가 동시에 접속했습니다. 우리가 흔히 생각할 수 있는 방식..

안녕하세요. 매일 성장하는 개발자 stark입니다!저는 실무에서 스프링 내부 이벤트를 발행할 때 @TransactionalEventListener(AFTER_COMMIT)를 정말 많이 사용합니다. 근데 after_commit 내부에서 트랜잭션을 사용해서 업데이트 처리를 해야 하는데 제대로 동작하지 않는 문제가 발생했습니다.분명 트랜잭션도 제대로 걸어줬는데 왜 업데이트가 안되는지 이 상황이 도저히 이해가 되지 않았고 저는 이해되지 않은 채로 넘어가는 것이 싫어서 정말 오랜 시간 동안 그 이유를 찾아 헤매었습니다. 조금 오래 걸렸지만 결국은 답을 얻었고 그 과정을 정리해 봤습니다.  문제 상황 이해하기게시글 저장 API를 호출하면 게시글을 저장하고, 그 과정에서 이벤트를 발행합니다. 이 이벤트는 @Tran..

안녕하세요. 기록이 즐거운 개발자 stark입니다!이번 포스팅은 제가 직접 겪은 Enum 오류와 그 해결 과정을 기록해 두고자 작성했습니다. 스프링 프로젝트에서는 DB에 저장되는 타입을 문자열(String)이 아닌 Enum으로 관리하는 것을 권장합니다. Enum을 사용하면 임의의 값이 DB에 저장되는 것을 방지할 수 있으며, 코드 내에서 타입을 쉽게 검색해 빠르게 확인할 수 있는 장점이 있기 때문입니다. 하지만, Enum을 사용한다고 해서 문제가 없는 것은 아닙니다. 프로젝트를 진행하면서 예상치 못한 문제에 직면할 수 있습니다. 제가 겪은 문제 상황은 다음과 같습니다. 비즈니스 로직에서 Enum을 사용해 DB에 저장된 특정 타입 값을 확인하고, 일치할 경우 데이터를 처리하는 로직을 작성했습니다. 그러나,..

안녕하세요. 자바 스프링 백엔드 개발자 stark입니다!실무에서 개발한 코드를 보면 비즈니스 로직이 엄청 긴 경우가 있습니다. 이 경우 내가 이렇게 열심히 작성했구나! 이런 뿌듯함을 느낄 수는 있지만 '근데 이거 뭘 작성한 거지?' 이런 생각이 들기도 합니다. 만약 작성한 코드 중간에 비즈니스가 추가되어 수정해야 하거나 개발 중에 잠깐 쉬다 와서 흐름을 잃었다면 '대체 내가 위에 어떤 비즈니스 코드를 작성했지?' 이런 생각이 들면서 모든 코드를 한 줄씩 다 천천히 읽어가며 이해해야 하는 상황이 발생합니다. 심지어 실무에선 내가 작성한 코드가 아닌데 수정해야 하는 경우도 정말 많기에 코드를 작성할 때부터 이해하기 쉽게 작성할 필요성이 있습니다. 그럼 어떻게 해야 우리가 작성한 코드가 읽기 쉬워질까요? 여러..

안녕하세요. 금요일이라 행복한 개발자 stark입니다!최근 stream에 대한 글을 자주 적고 있습니다. 왜냐하면 제가 실무에서 너무나도 많이 사용하기 때문입니다. 많은 데이터를 조립해서 가공하는 로직을 만들면서 느낀 점들이 굉장히 많다 보니 계속 기본적인 글을 적게 되는 것 같습니다.특히 저희 팀의 직속선배님께서 제가 forEach문을 사용해서 작성한 비즈니스 로직을 보시더니 stream의 anyMatch를 사용해서 코드가 개선되는 모습을 보여주셨습니다.저는 stream에서 이런 다양한 메서드를 지원한다는 것은 알았지만 어째서인지 잘 사용하지 않았고 항상 filter와 findFirst 같은 메서드만으로 모든 필터링을 하고 있었습니다. 그래서 이번 기회에 다양한 필터 방식과 왜 Stream이 forEa..

안녕하세요. 오늘도 개발 중인 stark입니다!최근 마이크로서비스 아키텍처(MSA)가 널리 도입되면서, 서비스 간 통신 방식에 대한 고민이 깊어지고 있습니다. 그중에서도 Google이 개발한 gRPC는 기존 REST API의 한계를 뛰어넘는 새로운 대안으로 주목받고 있습니다. 저 또한 MSA 프로젝트를 하면서 FeignClient의 대안을 알아보던 중 gRPC에 대해 알게 되었고 도입까지 해보게 되었습니다. 그러나 gRPC를 사용만 했지 무엇인지에 대해서는 이론적으로 잘 알지 못하고 있다는 것을 깨달았습니다. 그래서 이번 포스팅에서는 gRPC에 대한 경험이 아닌 이론을 정리해 보았습니다. 이번 포스팅을 통해 gRPC가 어떤 특징을 가졌는지 그리고 기존의 REST API와 비교했을 때 어떤 차별점이 있는지..

안녕하세요. 항상 졸린 개발자 stark입니다!오늘은 DDD에서 도메인을 잘못 설계해서 비즈니스 로직이 꼬인 상황을 살펴보고 이 비즈니스 로직을 리팩토링 해봅시다.특히 개발자의 적인 화살표 if문을 어떻게 도메인 객체로 풀어나갈 수 있는지 알아봅시다.  잘못 사용 중인 도메인을 살펴보자.잘못된 도메인 사용 사례는 코드의 비효율성과 유지보수의 어려움을 야기할 수 있습니다. 예를 들어, 도메인 객체가 단순히 데이터를 담는 역할만 하고 비즈니스 로직이 모두 서비스 계층에 존재하는 경우, 객체지향의 장점을 충분히 활용하지 못하게 됩니다. 도메인은 비즈니스 로직을 포함하여야 함에도 불구하고, 단순히 상태를 저장하는 데이터 전달 객체(Data Transfer Object, DTO)로만 사용되면 코드의 응집도가 낮아..