키워드 초성 검색 기능 개선 과정
·
Spring/프로젝트 리팩토링 회고록
[요구 사항]매칭 시 유저의 닉네임을 검색하는 기능 요구. 단, 유저의 닉네임 단어 일부를 검색하면 자동으로 키워드를 완성반려견 프로필 등록 시 견종을 검색하는 기능 요구. 단, 반려견의 견종 일부를 검색하면 자동으로 키워드를 완성반려견 견종이 없는 경우에는 유저가 직접 입력하여 등록직접 입력한 데이터는 견종 데이터 자동 완성 키워드에 출력되지 않음  [기능 구현방식 선정]구현 방식에 대해서는 세 가지 방법이 있었습니다.1. MySQL에 데이터를 저장하고 LIKE %keyword%를 사용한 검색2. Elastic Search를 사용한 형태소 단위 검색3. Redis의 ZSet [각 방식의 장/단점]1. MySQL 과 LIKE 함수 활용 1번의 과정은 견종 데이터를 정적 테이블에 삽입하고, 조회 시에는 L..
[회고록] Spring Boot에서 JPA의 Soft Delete와 Cascade 연관관계
·
Spring/프로젝트 리팩토링 회고록
내가 사용한 SQL Delete방식에서 Cascade속성을 함께 사용하려 했을 때 발생했던 아래의 문제에 대해 다시는 발생하지 않도록 개념을 다잡기 위해 정리한다! 이전에는 Cascade를 왜 사용하는지 잘 몰랐으나 SoftDelete와 함께 무턱대고 사용하려고 하니 충돌이 나서 각각의 방식과 전략을 확실히하고 어떤 방법으로 SoftDelete를 사용하며 Cascade는 왜 피해야 하는지 알아보자.[발생한 예외]org.hibernate.ObjectDeletedException: deleted instance passed to merge[Soft Delete의 적합성]Soft Delete는 데이터베이스에서 데이터를 물리적으로 삭제하지 않고, "삭제됨" 상태를 표시하기 위해 추가적인 컬럼(e.g., dele..
레이어 아키텍처 구조 개선하기
·
Spring/프로젝트 리팩토링 회고록
[문제점 성찰]현재 나의 프로젝트 구조는 신규 개발자가 대중적으로 사용하는 레이어 아키텍처를 사용 중이었다. 레이어 아키텍처는 가장 가시적이고 무언가 만들때 쉬운 방법이었다.하지만 단점이 존재한다. 첫 째, 모든 것이 영속성 계층을 기준으로 만들어진다. 우리가 개발을 시작하기 전에 가장 먼저 작성하는 것은 테이블 명세, ER 다이어그램이다. 각 엔티티의 관계를 고민하고 어떻게 연결하며, 어느정도 정규화를 통해 만들어낼지 고민하는 과정을 거치게 된다. 도메인을 먼저 고민하기보다 유스케이스를 통해 어떤 행위가 먼저 이뤄질지 고민하는게 맞는 것 같다는 어느 한 강의를 듣게 되었다. 다음 단점을 보며 내용을 이어나가겠다.둘 째, 계층형 아키텍처는 업무 도메인에 대해 어떠한 정보도 제공해주지 않는다.  실제로 모..
레이어드 아키텍처의 문제점과 해결방안
·
Spring/프로젝트 리팩토링 회고록
2024.11.30 - [Spring/프로젝트 리팩토링 회고록] - 레이어 아키텍처 구조 개선하기모든 테스트가  h2를 필요로 한다?설계가 잘못되었을 수 있다. 테스트는 외부 객체의 주입을 받지 않은 상태에서도 동작할 수 있는 유닛 테스트가 필요한 경우가 있기 때문이다.또한 작성한 테스트가 실제로 테스트가 필요한 본질적인 책임을 갖고있는 객체가 아닐 수 있다. 레이어드 아키텍처의 구조레이어드 아키텍처는 유사한 기능들을 하나의 계층으로 묶어서 각각의 책임을 지게하는 구조이다.가장 쉽고 눈으로 봤을때 한 눈에 보인다는 장점이 있어 가장 많이 쓰이기도 한다. 하지만 이 아키텍처는 여러가지 단점이 있다.아래 이유를 적어놨지만 한 마디로 말해서 절차지향적인 코드를 작성하게된다. 우리는 자바를 객체지향적인 특징이 ..