이번 포스팅은 실무에서 템플릿 메소드 패턴을 사용하여 중복되는 '행위'를 해결한 일지를 작성해보고자 합니다.개요실무에서 Google의 Firebase Cloud Messaging을 활용하여 푸시를 전송하는 로직을 개편했다. FCM을 활용하여 푸시를 전송할 때는 FCM에서 발급하는 '토큰'을 전송해야 한다. 이때 FCM 서버는 토큰을 최대 500개까지 허용한다. 만약 회원과 토큰이 일대일이라고 가정하자. 푸시를 전송해야 하는 회원이 2천명이라면, 한 번에 2천개의 토큰을 Request Body에 담아 FCM에 요청하면 예외가 터지는 것이다.따라서 프로젝트 설계를 아래와 같이 구성했다.public class ListExtractor { ... public ListExtractor(final long ex..

레코드는 무엇인가우리는 흔히 이런 경험을 한다. 고작 단순한 데이터를 운반하는 일을 하는 객체를 모델링할 때 과도한 모델링으로 오버헤드가 발생하는 경험 말이다. 예를 들어, 보다 정확하게 객체를 모델링하려면 생성자부터, equals(), hashCode(), toString() 등 반복적인 코드를 많이 작성해야 했다.레코드의 탄생은 이런 자바의 불편함에서 시작했다. 레코드는 코드를 들여다볼 때부터 “데이터 운반 객체”란 설계 의도를 파악하기 쉽다.다음 두 코드를 보면 그 차이가 확연히 들어난다.public final class UserInfo { public final String name; public final int age; public UserInfo(String name, int..

예외를 다루는 Best Practice가 있을까?자바의 예외에 대한 포스팅은 굳이 이 글이 아니고도 많은 블로그에서 찾아볼 수 있으므로 생략하겠다. 간단히 언급해보자면 Exception은 try-catch를 강제하며 try-catch에서 해결하거나 throws해야만 한다. Runtime Exception은 해결 불가능한 예외로 try-catch를 강제하지 않는다. 스프링에서는 하나의 트랜잭션에서 RuntimeException이 터지면 롤백되도록 설계되었다. 이 정도는 다 아는 내용이라고 생각하고 더는 생략하겠다.오늘 이 글에서 하고 싶은 말은 예외를 다루는 Best Practice가 있을지 고민한 글이다.그 중에서도,커스텀 예외는 언제 만들어야 할까?에 대해 글로 녹여봤다.글을 쓰게된 것은 사내 프로젝트..

클래스간 강결합 문제 회원가입 했을 때 환영 메세지를 보내는 비즈니스 로직을 개발하고자 한다. 보통 아래와 같이 개발하고자 할 것이다. class JoinService { void join() { // 회원 가입 로직... messageService.sendWelcomeMessage(message); } } 위처럼 코드를 작성할 때 무엇이 문제일까? JoinService와 MessageService가 강하게 결합하는 문제가 있다. 이런 강결합에는 다음과 같은 문제가 있다. 트랜잭션 문제이다. 도메인의 비관심사의 실패로 관심사에 영향을 미쳐서는 안 된다. 즉, 메세지를 보낼 때 실패해서 롤백되었어도 관심사는 롤백되어서는 안 된다. 반대로 관심사가 실패하면 비관심사도 같이 실패해야 한다. 즉, 회원가입이 실..

Mapstruct 빌드 시 발생하는 문제회사 업무 파악을 하다가 서비스 코드를 빌드하는데 아래와 같은 문구가 IDE에 출력되었다. No implementation was created for ExampleMapstruct due to having a problem in the erroneous element java.util.ArrayList.error: No implementation was created for ExampleMapstruct due to having a problem in the erroneous element java.util.ArrayList. Hint: this often means that some other annotation processor was supposed to p..

관계형 데이터베이스에서의 키(Key) 지난 시간에 이어 데이터베이스 개념들을 정리해보겠습니다. 테이블을 설계할 때 키들을 정해야 할 때가 옵니다. 그때 과거의 저의 경험에 빗대어 저술해보겠습니다. 데이터베이스 1 - 관계형 데이터베이스 개념정리(릴레이션, 튜플, 도메인) 기본 키 정하기 기본 키를 정하기 위해서는 기본 키의 개념에 대해 알아야 합니다. 제 과거 이야기를 해볼까요? 저는 국비 지원 학원을 다녔었는데요. 그때 한 동료 분이 최종 프로젝트를 준비하면서, 테이블 설계에 대해 고민을 하셨습니다. (개인 프로젝트여서 설계도 다 혼자 했어야 했습니다.) 그분은 테이블을 설계할 때 기본 키를 2개로 설정할지, 3개로 설정할지를 고민했었습니다. 저는 기본키를 한 개 이상 설정한다는 점에서 무언가 아닌거 ..

관계형 데이터베이스 수학과 관계형 모델에서 릴레이션의 차이 자료 구조 중 set은 서로 다른 요소를 가진 자료 구조로 순서가 없습니다. 이제 set이 두 개가 등장합니다. set A에는 a, b가 있고 set B에는 1, 2, 3이 있습니다. set A에서 하나의 요소를 고르고, set B에서 하나의 요소를 골랐을 때 가능한 모든 한 쌍의 조합을 릴레이션이라고 합니다. 위 이미지에서는 {a, 1}, {a, 2}, {a, 3}, {b, 1}, {b, 2}, {b, 3}이 있겠습니다. 이를 카테시안 곱이라고 하는데 수식으로 표현하면 A × B = {(a, b) | a ∈ A and b ∈ B}라고 합니다. 즉, A와 B의 카테시안 곱은 (a, b) 형태의 요소들로 이루어진 집합이며, 이때 a는 A의 원소이고..

이번 내용은 데이터베이스 시스템 책을 보면서 생각 및 공부 정리를 한 포스팅입니다. 관계형 데이터베이스 관계형 데이터베이스 구조 관계형 데이터베이스는 테이블의 모임으로 구성됩니다. 그리고 테이블은 각각 행과 열로 구성되어 있습니다. 테이블의 각 열은 속성으로 표현합니다. 만약 테이블의 열에 이름, 성별, 나이가 있다면 이것이 테이블의 속성입니다. 테이블의 각 행은 속성과 관계가 있습니다. 가령 이름이란 속성(열)의 행에 유재석, 박명수, 하하, 길이 있다고 합시다. 이때 행은 이름이란 속성의 관계를 표현합니다. 테이블은 이런 관계들이 모인 것으로 이를 릴레이션이라 표현합니다. 튜플은 자료 구조로 데이터의 리스트를 의미합니다. 릴레이션은 튜플의 집합이며 튜플의 순서를 보장하지 않습니다. 또한 릴레이션의 각..