NDM

구축일지 1편에서는 왜 자동화를 선택했는지, Jenkins 대신 GithubActions를 사용했는지 알아보았습니다 이번 2편에서는 CI/CD 자동화를 어떻게 했는지에 대해 서술합니다. 하나하나 다 알아보지는 않고, 핵심적인 몇몇 단계만 짚어서 보겠습니다 전체 워크플로우는 다음과 같습니다. # application.properties 설정 파일 숨기기 특정 브랜치로 체크아웃 -> Java11 설정 -> Build까지 별 다를게 없는 설정입니다. 다만, make application.yml을 봐주시길 바랍니다. 저는 SpringBoot로 프로젝트를 진행하고있고, SpringBoot의 application 파일에는 설정정보들이 담겨져있습니다. DB의 host나 username, password등이 그 예시이..

배달 서비스를 구현하는 slowDelivery 프로젝트 진행중입니다. 주문 로직에 대해 제가 고려한 것을 포스팅 하려고 합니다. 도메인은 장바구니 / 상품/ 재고 / 가게 / 주문이 있으며, 결제API는 클라이언트쪽에서 연동하기 때문에 결제데이터를 save하는 정도로만 구현했습니다. 장바구니와 재고는 Redis로 되어있으며, 나머지는 RDB를 사용했습니다. 재고에 Redis를 사용한 이유는 https://ndm-tech.tistory.com/34 에 기록해 두었습니다. 이번 포스팅에서는 아래의 내용을 다룹니다. 주문 로직의 순서를 결정하게 된 고민 과정 프로젝트를 진행하며 처음에 고생했던 부분은 주문이 성공하고 나서야 재고를 감소시켰었다는 점 입니다. 이것은 실제 상황과 비교해 볼 때, 가장 유사한 순서..

배달 서비스를 구현하는 slowDelivery 프로젝트 진행중입니다. 주문 로직에 대해 제가 고려한 것을 포스팅 하려고 합니다. 도메인은 장바구니 / 상품/ 재고 / 가게 / 주문이 있으며, 결제API는 클라이언트쪽에서 연동하기 때문에 결제데이터를 save하는 정도로만 구현했습니다. 장바구니와 재고는 Redis로 되어있으며, 나머지는 RDB를 사용했습니다. 제 프로젝트의 주문 제한사항은 다음과 같습니다. 장바구니를 거쳐서만 주문할 수 있으며, 장바구니에 다른 가게의 상품을 담을 수 없습니다. 주문 로직의 순서 주문은 다음과 같은 순서로 이루어집니다 장바구니와 가게 데이터를 조회해 주문 객체를 만듭니다. 가져온 데이터로 검증을 시작합니다. ( 가게가 오픈했는가 / 주문 금액이 가게의 최소주문금액을 넘어섰는..

배달 어플을 구현하는 SlowDelivery 프로젝트에서 재고를 처리하는데 동시성 이슈가 있었습니다 더보기 하지만 사실 재고 도메인은 필요가 없었는지도 모릅니다. 일반적인 쇼핑몰과 다르게 배달 어플은 판매중인 상품의 재고를 숫자로 나타내지 않고 각 가게마다 유연하게 판매 가능 / 판매 불가능 상태값을 바꿔주는 로직만 작성해주면 굳이 재고의 증가/감소를 구현할 필요는 없었을 수도 있습니다. 하지만 이 프로젝트는 순수하게 학습용이고, 취업 시 [이런것도 구현하고 고민해 보았다] 를 어필하고 싶었고, 무엇보다 이커머스 분야에서 일하고 싶다면 한번쯤은 경험해보는게 낫겠다 싶어 억지로(?) 끼워넣은 도메인입니다 때문에 프로젝트 주제나 도메인에 있어 어색함이 있을 수 있습니다 현재 제 프로젝트의 주문 로직은 주문접..