hojak99 의 블로그

좋지 않은 테이블 구조에서의 개발을 어떻게 해야할까..? 좋지 않은 테이블 구조라고 했는데 우선 정합성이 다 깨져버려있다는 것을 의미하고 있다. 그리고 특정 A, B 테이블의 의존관계가 1 : N 이 될 수도 있고, 1 : 1 이 될 수도 있다. 백엔드에선 JPA, querydsl 을 사용해서 의존관계 맺어서 one to one, one to many 등을 이용해서 각 기능들을 구현하고 있었다. 그런데 테이블 구조가 썩 좋진 않다보니 쉽게 개발하려고 JPA 를 사용하는데 비즈니스 코드가 너무 복잡해지거나, 테이블 구조가 이상한데 이걸 다시 코드로 구현하자니 코드도 썩 좋지 않게 되는 것 같았다. 그래서 우선 각 엔티티 별로 모두 다 쪼개고 의존관계 맺지 않고 무조건 코드에서 각 엔티티를 조합해서 사용하는..

클래스 명에 상위 패키지 명이 들어가야 할까? 에 대한 얘기를 해보려고 한다. - com.hojak.test - service - recommend - RecommendBookService.class 내가 진행하고 있는 프로젝트에 패키지 구조가 이렇게 돼 있다고 해보자. recommend 패키지 내에 `RecommendBookService` 클래스가 존재한다. 회사 시니어 개발자분께서 굳이 `RecommendBookService` 클래스 이름에 `Recommend` 라는 단어를 붙일 필요가 있는가? 라는 이야기를 해 주셨다. 이미 패키지에서 `recommend` 라고 표현하고 있는데 굳이 클래스에서 또 `recommend` 라는 단어를 사용할 필요가 있냐는 이야기신 것 같다. 그래서 생각해보니 굳이,,?..

지금 보니 좀 문제가 있어 보인다. DTO 로 convert 하는 식으로 하면 JPA 를 사용하는 이유가 없어진다. 애초에 서로 도메인의 경계를 잘 나누면 된다. 그래도 옛날의 나의 생각이었기에 글은 냅두도록 한다. 개발을 하다 보면 레이어 분리를 어떻게 해야 잘 하는지에 대한 고민을 하게 된다. 모놀리틱에서 개발을 한다고 했을 때 보통 나는 다음과 같은 레이어로 분리를 하여 개발을 하게 된다. - serivce - repository - domain - controller 일반적인 jpa + spring 사용 시에 나오는 패키지 구조이다. presentation, business, persistence 레이어로 분리했다고 볼 수도 있을 것 같다. service 클래스에서는 repository 나 다른 ..

개인적으로 진행하는 프로젝트에 로그인 보안에 jwt 을 이용하려고 하고 있다. 이 때 jwt 사용 시 refresh token 은 어디서 관리해야 할까에 대해서 굉장히 많은 고민을 했다. refresh token 은 어디서 관리해야 할까? 우선 토큰 사용의 목적은 stateless 하게 가져가기 위함이다. 세션을 사용한다면 매 요청마다 redis 든 DB 든 어디선가 세션 정보를 저장하고 있고, 이 세션이 올바른지 체크를 하게 된다. 이 때 토큰을 사용 시 토큰이 유효한가? 에 대해서만 체크하면 되는데 이 때 access token 과 refresh token 으로 관리를 하게 된다면 access token 으로 유효성 검증 후 access token 내에 만료 시간 데이터를 넣어서 매 요청마다 단순히 ..

jpa 에서는 테이블 별로 엔티티 클래스를 생성해서 개발을 하고 로직으로 구현하면 됐었으나, mybatis 에서는 어떻게 개발을 해야 좋은 구조가 될 지 고민을 하고 있다. 우선 mybatis 로 jpa 처럼 구현을 하자니 mybatis 의 장점, 특징들을 못 살리는 것 같아서 애매하고, 도메인이 복잡해서 여러 테이블을 조인해서 사용하는데, 조인해선 나오는 필드들로 매핑 클래스를 생성하니 다른 곳에서 사용하기 애매하다,, 그래서 쪼금 다르게 매핑 클래스를 만드니 중복되는 필드들이 우후죽순으로 생겨나 버리고 관리하기 힘들어지는 것 같다. 또 그렇다고 그냥 불필요하게 조인되는 매핑 클래스를 이용해버리면 단일 책임 원칙을 위배되고 처음에 말했던 것처럼 불필요한 조인을 해버리니,,,,, 어떻게 해야 좋은 구조로..

DB 를 잘 모르거나 지식이 없는 채로 서비스를 개발할 때 누군가 이 글을 보고 이렇게 하면 안되는구나! 라고 생각했으면 하고 글을 작성해본다. 문제 상황 동시에 회원가입 요청이 들어왔을 때 중복되는 ID 값을 갖게 돼 2명의 사용자의 데이터가 하나의 ID 를 갖게 되는 상황이 발생했다. 그리고 다른 테이블에서는 해당 키를 외래키로 사용을 하는데 A 란 사용자로 인해 생긴 데이터인지, B 라는 사용자로 인해 생긴 데이터인지 판단할 수 없게 되었다. 결국 해당 데이터들은 모두 제거하게 되었다. 그렇다면 왜 이런 상황이 발생했을까? 원인 서버에서는 해당 ID 값을 직접 생성하고 있었다. 가장 마지막 ID 값을 가져와 + 1 을 하여 값을 넣어줬고, 아마 요청이 동시에 일어나거나, 트래픽이 많지 않기 때문에 ..

현재 다니고 있는 회사에서 제공하는 서비스는 전형적인 모놀리틱 시스템이다. 같은 회사 동료와 MSA 로 새롭게 서비스를 구축하자라는 공통된 의견을 가졌다. 그 이유는 기존 서비스 구조는 어딘가를 수정하려면 그와 함께 봐야하는 코드가 많고 비즈니스 로직이 너무 촘촘하게 결합 돼 있었기 때문이다. 여기 한군데 건들면 모든 코드가 영향을 받는다. 우선적으로 DB 구조도 뭔가 분석하거나 쌓인 데이터를 통해 인사이트를 얻을 수 있는 그런 좋은 구조가 아니였고 불필요한 컬럼 및 테이블이 쌓여있었다. 현재는 다른 개발자 분들께 현재 서비스에서 나중에는 이런 식으로 서비스를 나누고 DB 는 이렇게 나눴으면 좋을 것 같다. 라는 것까지 이야기가 됐다. 그러나 현실적으로 보았을 때 3년도 채 되지 않은 스타트업에서 기존 ..