Architecture

Trade-Off(구조의 안정성 vs 단순한 개발의 편리성) 스프링 데이터 JPA 예제를 수행한 것을 다시 한번 돌아보며, 느낀 것들을 기록한다. 우선, DI, OCP를 지키기 위해 어댑터를 도입한 코드의 클래스 의존 관계와, 런타임 객체 의존 관계를 살펴보자. 중간에서 JpaItemRepositoryV2가 어댑터 역할을 해준 덕분에 ItemService가 사용하는 ItemRepository 인터페이스를 그대로 유지할 수 있고, 클라이언트인 ItemService의 코드를 변경하지 않아도 되는 장점이 있다. 그런데, 여기서 고민이 생긴다. 구조를 맞추기 위해서, 중간에 어댑터가 들어가면서 전체 구조가 너무 복잡해지고 사용하는 클래스도 많아지는 단점이 생겼다. 실제 이 코드를 구현해야하는 개발자 입장에서 보..

Querydsl을 이용한 리팩토링 (feat. 쿼리 조각화) Querydsl을 공부하다가, 예제코드를 보고, 당연한 것임에도 정말 좋은 방법이다 라는 생각이 들어서 글을 남긴다. Before Refactoring Code 리팩토링을 하기 전의 코드다. Querydsl을 이용하여 동적쿼리를 작성한 코드다. 만약 검색 조건으로 들어온 itemName이 like검색을 수행하고, 없으면 like 검색을 하지 않고, 만약 검색 조건으로 들어온 maxPrice가 null이 아니면 and 조건을 달아서 >= maxPrice 를 수행하고, null이면 안하는 이러한 로직이다. 그런데, 여기서 조금더 코드를 개선했더니 많은 이점을 얻을 수 있었다. 우선, 리팩토링한 코드를 보자. After Refactoring Code..

최근에 백엔드 공부를 시작하면서, 재미있는 하루하루를 보내고 있다. 스프링을 이용해서 간단한 회원관리서비스를 만들었는데, 정말 간단한 프로젝트여도 얻은 것이 정말 많은 프로젝트였다. 특히나 설계의 중요성을 다시한번 깨닫는 개발이었다. 서비스의 비즈니스 요구사항 요약하자면, 이름을 설정하여 회원가입 존재하는 회원의 이름과 같은 이름으로는(중복 이름) 가입 불가 아직 데이터 저장소가 선정되지 않은 상태(가상의 시나리오) 이러한 비즈니스 요구사항을 가정하고 만든 서비스이다. 회원의 이름 데이터를 저장하는 저장소가 아직 선정되지 않았기에, MemberRepository라는 이름으로 인터페이스를 만들고, 처음에는 간단하게 자체 메모리에 저장하도록 MemoryMemberRepository라는 이름으로 구현체를 작성..