프로젝트 기록 (9) 썸네일형 리스트형 241218 프로젝트 마무리 회고 TIL 2차 프로젝트가 마무리되었다!https://github.com/Sparta-Phoenix/logistics-platform GitHub - Sparta-Phoenix/logistics-platformContribute to Sparta-Phoenix/logistics-platform development by creating an account on GitHub.github.com 프로젝트 마무리 기념으로 개인적으로 아쉬웠던 점들을 간단히 기록해보고자 한다. 1) 캐싱을 더 잘 활용할 수 있었는데 아쉬웠다.시간관계상 필수 요구사항인 허브 단건 조회에만 캐싱을 적용했는데, 생각해보니 업체 관리자들도 정보를 빈번하게 조회할 것 같았고 목록 조회도 자주 일어날 것 같아서 업체 단건 조회와 페이징에도 캐싱을 적.. 241210 프로젝트 TIL 도메인 주도 설계 (DDD, Domain-Driven Design) 프로젝트 구조 설계하기1) application 계층비즈니스 로직을 실행하고, 도메인 모델을 조작하며, 외부 인터페이스와 도메인 간의 중재 역할을 수행한다.- 외부와 연결되는 service - 애플리케이션 내부에서만 사용되는 dto (요청/응답 x) 2) domain 계층애플리케이션의 핵심 비즈니스 로직과 규칙을 포함한다.ex) model, repository, 핵심 비즈니스 service (외부와 연결 x)- model - 인터페이스만 있는 repository (추상화) 3) infrastructure 계층외부 시스템과의 통합을 담당하며, 기술적인 세부 사항을 처리한다. - configuration- domain 계층의 인터페이스를 구.. 241119 프로젝트 TIL 오늘은 프로젝트 발표회를 진행했다. 발표를 맡으신 분이 발표 준비를 하시느라 많이 고생해 주셨다.나는 내가 개발한 부분에 대한 예상 질문을 몇 개 준비해 보았다. 먼저 주문 방식 선택이 나에게 문제가 됐던 이유는 온라인 주문은 장바구니 추가 후 주문 생성, 결제를 하면 되는데대면 주문의 경우 가게 사장님이 직접 고객이 원하는 메뉴를 담아야 했기 때문에 장바구니 없이 이를 어떻게 구현할지가 고민이었다.그래서 대면 주문 방식도 온라인 주문처럼 장바구니 추가 -> 주문 -> 결제 로직을 똑같이 구현하되, 서비스를 분리했다. 여기서 동일한 로직인데 서비스를 분리한 가장 큰 이유는 온라인 주문의 경우 배달비와 쿠폰 사용 여부를 고려해야 했기 때문이다. 대면 주문은 배달비와 쿠폰 사용을 하지 않기 때문에 서로 다른.. 241118 프로젝트 TIL 오늘은 프로젝트 마무리에 Swagger을 적용하여 API를 문서화했다. Swagger 세팅 & 사용법에 대해 간단하게 정리하겠다. 1) 먼저 build.gradle에 의존성을 추가한다.implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.0.2' 2) 설정 파일을 추가한다.Configurationpublic class SwaggerConfig { // OpenAPI 설정 @Bean public OpenAPI openAPI() { String jwt = "jwt key"; SecurityRequirement securityRequirement = new SecurityRequirement().add.. 241115 프로젝트 TIL 오늘은 장바구니 생성 테스트 코드와 고객 주문 생성 테스트 코드를 작성했다.그 중 고객 주문 생성 기능에서 성공 테스트 케이스를 검증할 때 1) 예외를 던지지 않는지?2) 최종 주문 가격이 [(메뉴 가격 * 카트에 담은 개수) + 배달비 - 쿠폰 할인가격 (쿠폰 적용 시에만 해당)]과 일치하는 지?를 검증했다. 테스트가 실제 DB에 영향을 주지 않게 하고 싶었기 때문에 Mock 테스트를 작성했다.테스트를 위해 생성한 더미 테스트 데이터의 시나리오는 다음과 같다.먼저, 성공 케이스는 쿠폰을 사용한 경우와 쿠폰을 사용하지 않은 경우 2가지로 생각해야했다.User에게 발급됐다고 가정한 쿠폰이 2000원이기 때문에 쿠폰을 사용한 request를 받으면 최종가격은 16000원, 쿠폰을 사용하지 않은 request.. 241114 프로젝트 TIL 엔티티 조회 시 연관관계 엔티티 null 이슈오늘은 결제 생성 기능과 결제 조회 기능을 구현했다. 결제(payment) 테이블은 주문(order) 테이블과 1대1 매핑되어있다.그런데 개발 중, 결제 조회 시 User의 주문 내역을 조회한 후 order의 payment를 찾는데 NPE가 터져서 그 이유를 찾아봤다.order의 DB를 보니 payment가 null로 들어가 있었다. 왜 그런지 코드를 보며 생각하다가 깨달은게 order가 먼저 생성되고 나중에 결제 생성 시 payment가 생성되므로 결제 생성 시 직접 order에 payment 정보를 넣어주지 않아 당연한 결과였다...이를 깨닫고 결제 생성 시 order의 payment에 해당 결제 엔티티를 저장해주었고, 다시 조회 기능에서 해당 주문의 결제.. 241113 프로젝트 TIL 주문 기능 리펙토링오늘은 주문 기능을 전체적으로 리펙토링했다. 먼저 OrderService 코드안에 Customer의 코드와 Owner의 코드가 섞여 있으니 내가 보기에도 불편했고, 다른 개발자분들이 보시기에도 헷갈리실 것 같아서 분리하고 공통기능만 OrderService 안에 넣어두었다. 그리고 주문 생성 시, 쿠폰을 적용하는 로직을 원래 주문 객체 생성 전에 진행하고 한번에 객체를 생성했는데, coupon 기능을 개발하신 분의 쿠폰 적용 서비스 코드를 보니 쿠폰 적용 시 order객체가 함께 들어가야했다. 그래서 이에 맞춰 개발하기 위해 주문을 먼저 생성해 저장하고, 쿠폰 적용 시 할인 가격과 총 금액을 업데이트 하는걸로 로직을 변경하였다.이렇게 변경하니 최종적으로 코드가 훨씬 깔끔해졌고 기능 분.. 241112 프로젝트 TIL 주문 CRUD 기능 개발 과정오늘은 어제 계속 고민하던 주문 생성 로직을 완성했다. 이번 프로젝트 요구사항 중 - 고객은 배달 주문 방법과 포장 주문 방법 총 2가지 방법을 선택할 수 있다.라는 요구사항이 있었다. 배달 주문에서는 장바구니에서 원하는 메뉴들을 선택한 후 하나의 주문리스트로 만들고 테이블에 넣은 다음, 결제하면 되는데 포장 주문은 어떻게 구현해야할지 고민이었다. 포장 주문은 매장에서 결제를 한다는 조건이 있었다.그래서 고객이 배달 주문과 포장 주문을 둘다 직접 주문테이블에 넣는게 아니라, 고객은 배달 주문만 생성할 수 있고, 가게주인은 포장 주문만 생성할 수 있게 해야겠다고 생각했다.그래서 고객(Customer)과 가게주인(Owner) 권한을 가진 유저를 각각 분리한 주문 CRUD API를.. 이전 1 2 다음
