제품 재고 관리 시스템

회사에서 프로젝트를 진행하다보면 하나의 사이클을 처음부터 끝까지 돌리는게 쉽지 않다 😹내가 처음부터 끝까지 담당할 수 있는 토이 프로젝트를 해보고 싶다,,! 라는 생각이 들던 중, 친구가 하나의 제안을 해왔다누나가 아이디어스, 네이버 스토어 등에 직접 만든 제품을 판

회사에서 솔루션을 개발하며 느낀 것은 설계의 중요성이다. 설계가 바뀌는 일이 많을수록 개발에 걸리는 시간은 점점 늘어난다. 하지만 회사에서 프로젝트 "전체"에 대한 설계를 진행할 일은 많지 않기에, 토이 프로젝트를 진행하면서 전체적인 설계를 해보는 일은 설레는 일이

지난 포스트에 이어, 제품 재고 관리 시스템의 ERD 설계를 마무리하고, 테이블 정의서를 작성하였다. 🤩완성된 ERD와 테이블 정의서는 다음과 같다. 각 테이블간의 관계(pk-fk 관계선)도 작성하였다. product 테이블 중복 칼럼 (price, cost) 삭제s

ERD로 설계한 내용들을 JPA Entity로 표현하기 시작했다.기본적인 제품과 제품 카테고리의 CRUD operation을 수행하기 위해, product와 category entity부터 생성하였다. product와 category 모두 primary key는 Str

드디어 API 생성을 시작하였다,,!제품 재고 관리 시스템에서 메인이라고 할 수 있는 👜제품👜에 대한 등록 API를 생성해보았다 method: POSTendpoint: /api/v1/productRequest Body Example제품을 등록하려면 이미 catego

이전 포스팅에서 JPA Entity 설계 시, 각 테이블의 Primary key 값을 구분 문자 + "\_" + sequence 의 형태로 만드는 계획을 세웠다 하지만, sequence의 관리 (증감)을 서비스 단에서 조절하게 되면 제품 등록|삭제|업데이트 등 다양

지난 포스팅에서 개선이 필요한 사항에서, API 요청 성공|실패 시 메세지를 간결하고, 통일성 있게 바꾸기로 계획했었다 👾 이를 적용해보고자 한다!기본적인 HTTP 응답 코드, 응답 메시지와 함께, 요청을 받은 시간을 return 하는 객체를 생성하였다requestB

프로젝트 진행 상황제품(product)와 카테고리(category) entity에 대한 기본적인 CRUD API를 완성하였다. 그 중, 제품|카테고리를 업데이트하는 API 생성 시, Input에 Validation을 걸기 위해 사용한 annotation들에 대해 기록

제품, 카테고리, 사용자에 대한 기본적인 CRUD API만 만들었는데도, API의 수가 많아졌다 이에 이를 간단하게 문서화하여, Frontend 화면을 만드는 친구에게 남기기 위해, 그리고 나 스스로를 위해 (시간 절약,, 👻) Swagger 를 도입해보았다 정의

프로젝트에서 API 요청에 대한 권한을 부여할 때, 유저마다 Bearer token을 부여하는 방식으로 인증을 진행하였다. (유저가 로그인에 성공하면 token을 부여하는 방식) 이를 Swagger에 적용시킨 과정을 기록하고자 한다Bearer = 소유자토큰을 전송하는

Spring Boot에서는 MultipartFile 형식을 사용하여 파일을 input으로 받을 수 있다. 이 때, 다수의 입력 변수 및 Multipart 파일을 함께 처리해야 할 경우 @ModelAttribute를 사용하여 API 요청에 필요한 여러 입력 변수와 파일을

목록 페이지를 구현할 때 목록에 속한 요소의 개수가 너무 많거나, 이력 관련 페이지인 경우 모든 요소들을 한 번에 보여주지 않고 페이지를 나눠서 제공한다. JPA에서는 한 페이지 당 표출할 데이터의 크기, 조회하고 싶은 페이지가 몇 페이지인지, 정렬 방식등을 받아 쉽게

자바에서 안정적이고 버그 없는 코드를 작성하기 위해서는 올바른 동등성 체크가 중요하다. 자바 7에서 도입된 Objects.equals 메소드는 두 객체간의 동등성을 비교하는 ⭐null-safety⭐한 방법을 제공한다 기본 사용 예시 토이 프로젝트에서 update 기

객체 변경 감지란? > 데이터를 업데이트할 때 변경이 실제로 필요한지 여부를 판단하는 메커니즘이 필요한데, 객체의 이전 상태와 새 상태를 비교하여 변화가 있었는지 확인하는 것이 바로 객체의 변경 감지이다 프로젝트를 진행하면서 product, store, catego

토이 프로젝트의 진도가 잘 나가지 않는 느낌이 들었다 🫨🫨계속해서 API 만들고,,, test를 하고는 있었지만 핵심 기능들이 만들어지지 않아 그 원인을 찾고자 했다!!가장 시작하기 두려웠던 부분은 통계였다. 이익, 순이익을 구할 때 상점의 종류(수수료를 받는지,

Don't Repeat Yourself, 중복을 최소화하여 소프트웨어의 유지보수성을 향상시키는 핵심 원칙. 코드의 중복을 줄이고 유지보수성을 향상시킴매장 제품의 판매 이력, 매장 제품 관련 API들을 생성하다보니위와 같은 내용을 반복적으로 확인해야만 했다. 이에 같은

제품 재고 관리 시스템에 필요한 API 생성이 1차로 끝이 났다🔥🔥그래서 frontend 완성 후에 배포를 위한 Fat-jar을 생성하는 스크립트를 생성해보았다모든 의존성에 있는 라이브러리가 자체 포함되어있는 jar 파일. java -jar 명령어로 단독 실행 가능

제품 관련 Toy 프로젝트를 진행하다보니, errorCode와 response가 객체만 다를 뿐, 에러 코드와 에러 메시지가 반복되는 것을 확인할 수 있었다. 일관된 응답 처리를 하면, 유지보수성이 좋아지고, 확장성도 커지기때문에 ResponseCode enum을 생성

JPA와 어노테이션 정리org.springframework.data.jpa.domain.SpecificationSpring Data JPA에서 Specification은 repository 계층에서 복잡한 쿼리 조건을 생성하고 조합하기 위한 인터페이스JPQL 을 직접

안건: 재고 관리 시스템 1차 버전 점검 및 시스템의 발전 방향 논의1차 버전 배포 결과(프로토타입)를 보고, 실 사용자와 회의를 가져, 요구 사항을 듣고 추가 개발 방향을 구체화일시: 2024.02.18제품, 재료의 재고 관리 기능제품, 재료 등록/수정/삭제 기능제품

배경 서버의 DB 백업/복구 기능을 만들다 보니 Test 서버가 필요했다. 운영 중인 서버에서 직접 테스트 할 수 없었고, 로컬이랑은 환경이 달랐기 때문이다(로컬은 window, 운영 서버는 우분투) 그래서 테스트 서버를 하나 더 생성해 테스트 서버에 제품 관리 시스템

개요 이전 포스팅에서 시스템의 실 사용자와 미팅 후, DB 백업/복구 기능의 필요성을 느꼈다! 그래서 crontab을 사용한 스케줄러로 DB를 주기적으로 백업하고, API를 사용해서 원할때 복구하는 기능을 생성하였다 또한 백업 파일이 지나치게 많이 쌓이면 용량을 너무

자바 개발을 하다 보면 데이터 모델 간 변환을 흔히 겪는다. 특히 서비스 계층에서는 다양한 객체들 사이의 변환 작업이 필수적인데, 이러한 작업을 간편하게 해주는 도구 중 하나인 ModelMapper에 대해 기록하고자 한다자바 객체 간의 자동 매핑을 지원하는 라이브러리로

한 엔티티가 같은 엔티티의 다른 인스턴스를 참조하는 방식. 조직 구조나 카테고리 계층과 같은 계층적 데이터를 표현할 때 유용하지만 자기 참조 구조는 잘못 관리될 경우 무한 순환 참조라는 문제 발생 가능 -> 데이터베이스 쿼리가 무한 루프에 빠짐위와 같이 필기구 카테고리