최종프로젝트 회고록

최종 프로젝트 기본사항

• 팀 이름 : 10-trillion-dollars
• 팀 인원 : 5명
• 주제 : 이커머스
• 기간 : 24.3.26 ~ 24.4.30
  • 중간발표 : 4.15 14:00
  • 최종발표 : 4.29 14:00
• 일정 관리
  • 3.26(화) ~ 3.28(목) : 각 도메인 별 CRUD 완성
  • 3.29(금) ~ 4.9(화) : 각 파트별 기술 구현 / MVP 완료
    • Part1(1) : Redis를 이용한 동시성 제어 및 락 구현
    • Part2(1) : S3를 이용한 이미지 제어 및 카카오 데모 결제모듈 적용
    • Part3(2) : Docker-compose & EC2를 이용한 호스팅 및 CI/CD 구축 & HTTPS 적용
    • Part4(1) : 모놀리식 아키텍쳐를 MSA로 변경 & MSA 로그관리를 위한 ELK 구축
  • 4.10(수) ~ 4.14(일) : 진행한 내용 문서화 및 유저테스트를 위한 프론트 구현
  • 4.15(월) : 중간 발표
  • 4.16(화) : 다른 팀과의 전격적 코드리뷰
  • 4.17(수) ~ : 유저 테스트 및 회의 후 추가 스코프 적용

최종 프로젝트 회의록

3.26 회의록

• 회의 내용

1. 주제 선정 : 이커머스
   (서비스적으로는 흔한 내용이지만 기술적 성장을 도모하기 좋은 주제라고 생각해서)
2. 기능 설정 : 기초 도메인 설계 - 유저, 주소, 상품, 주문, 주문 상세
3. DB 설계 : MYSQL에서 실질적으로 연관관계는 사용하지 않지만 JPA를 쉽게 사용하기 위해 @ForeignKey(ConstraintMode.NO_CONSTRAINT) 사용
4. 와이어 프레임 : 프론트적인 성장을 도모하지 않아 유명한 이커머스 요소 가져왔음

public class Product{

    // ID 및 추가 필드들.../

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private User user;
}

3.27 회의록

• 회의 내용

1. API 명세서 작성 : 각자 맡은 도메인에 대해서 필요한 기능 작성 후 모두가 검토
2. CRUD 데드라인 생성 : 3.29(금) 20:00 까지
   • 설계 부분에서의 추가 의견 반영
     Order와 OrderDetail 사이의 관계가 너무 깊어 2명이서 나누는 것 보다 1명이 하는것이 효율적이라는 의견
     => 기본 CRUD가 너무 많아서 시간을 잡아먹는다 생각한 리뷰 도메인 추가
3. CRUD 이후의 스코프 생성(적용해보고 싶은 기술)
   • Redis를 이용한 락 & 캐싱 - 2명
   • 도커 + EC2 - 2명
   • MSA 적용 - 1명

3.28 회의록

• 회의 내용

1. response 타입 변경
   • front에서 작업할 때를 생각하여 각 객체의 ID 값을 포함해야 한다는 의견 적용
2. Order 설계 문제 해결 방식 논의
   Address를 직접 매핑하고 있지 않아 매핑되어있는 User를 통해 Address를 가져와야 한다. 그렇게 되면 유저는 하나의 주소만 가지게 됨
   • 의견 1 : Address에서 주소를 생성할 때 이미 주소가 생성되어있으면 생성이 불가하도록 구현
   • 의견 2 : Order에서 Address를 가지고 있도록 Entity 수정 (채택)
3. 일정 재확인 : CRUD의 진행속도가 빠름 - 3/28 14:00 완료
4. 외부 조언 : mvp에 결제파트를 도입해야한다.
   • 추가구현 기능에서 결제파트를 하고싶은 사람이 있을 경우에는 결제모듈 도입
     그렇지 못하면 포인트제도를 도입할 예정(결제 모듈 도입 결정)

4.1 회의록

• 회의 내용

1. 진행 상황 공유
   • 락 & 캐싱 : 진행 중 (테스트 코드로 테스트 중) / 데드라인 4/2(화)
   • 결제 모듈 : 카카오 단건 결제 (구현 90% 완료 테스트 중) + 취소 메서드 추가 생성
   • 도커 & EC2 & CI/CD
     진행에 막히는 부분이 많음 AWS를 미루고 도커 쪽 우선(이미지 빌드 해서 도커 허브에 올려둠) + EC2에서 가져오기 시도 + 샘플 프로젝트로 github actions를 사용해 CI/CD 시도
   • MSA : CRUD만 완성된 모놀리식 아키텍쳐를 MSA로 변경에 성공

4.3 회의록

• 회의 내용

1. 진행 상황 공유
   • 락 & 캐싱 : 테스트로 jmeter를 사용 - 오류를 발견하여 확인 중
   • 결제 모듈 : 실제 데이터베이스에 반영 작업
   • 도커 & EC2 & CI/CD : 추가 진행이 어려움
   • MSA : 각각의 서버 repository 의존성 제거 중, jwt 공유 라이브러리 생성 완료

4.5 회의록 - 외부참관(튜터님)

• 회의 내용

1. 전반적인 프로젝트 설정
   • 코드 컨벤션 : java-google-style.xml 사용 중
   • Github Rules : Merge는 1명 이상 approve했을 때 가능. + Gitmoji 사용을 통한 분류
2. 이번주 진행사항 공유
   • 결제 모듈을 제외한 CRUD 완료
   • 락(상품 개수) + 캐싱(각 파트 조회)
   • 기본 CRUD MSA 분리 완료 및 테스트 용 프론트 일부 구현(타임리프 및 Feign)
   • 도커 EC2 파트 중 깃허브 PR 이후 도커허브에 자동 이미지 생성 완료
   • MSA 프론트 파트 fetch → Feign으로 일부 변경)
3. 다음주까지의 목표
   • jmeter를 통한 동시성제어 테스트 완료
   • 카카오페이 결제 모듈 정상 적용 + S3 이미지 활용
   • 배포 완료 및 MSA 구조 프로젝트 배포 준비
   • MSA 통신 원할하게 오류 없이 고도화 및 시간이 남으면 ELK까지

4.8 회의록

• 회의 내용

1. 진행상황 공유
   • 락 & 캐싱 : 구현 및 테스트 완료 & 락을 생성하는 부분에서의 문제점 발생
   • 카카오 결제 모듈 성공 & S3 버킷 생성
   • CI/CD 파이프라인 완성
   • ELK 구축 성공 데이터 받는데 문제 없음
2. 문제점 회의 : 주문에서 락이 걸려있는데 상품이 100개가 있는데 주문에서 100개를 신청하고 결제를 하지 않으면 아무도 물건을 구매하지 않은채로 묶여있는 문제 발생
   => 결제모듈쪽으로 락 적용을 이동 / 카카오 QR결제까지는 이동이 가능하지만 실제 결제 요청은 락이 걸려있어 순서대로 결제 및 상품 수량 변경으로 해결

4.9 회의록

• 회의 내용

1. 진행상황 공유
   • 락 & 캐싱 완료 후 프론트 작업 시작
   • S3 이미지 업로드 및 다운로드 완료
   • Docker-Compose & EC2 & CI/CD : MSA 프로젝트 자동 CI/CD 완료 & HTTPS 적용
   • MSA Feign을 통한 통신 & 공유 라이브버리 & ELK까지 완료
2. 추후 진행상황 회의
   • 우선 기존 예상 스코프는 완성
   • 이번주는 기존에 진행한 내용에 대해서 문서화 및 프론트 작업
   • 일부는 서브도메인 적용 및 CORS문제 해결
   • 중간 발표 이후에 추가적인 스코프를 진행할지는 추후 다시 논의

4.11 회의록

• 회의 내용

1. 진행상황 공유
   • 기존 설계 스코프 모두 완료
   • 3팀으로 분류 (프론트, 중간발표, 상주)
2. 문제점
   • 프론트를 작성하면서 필요한 내용이 모자라거나 흐름이 유연하지 못하거나 하는 문제가 발생
     => 1명이 상주하며 프론트 팀의 요구사항 서버에 적용