2.14 화요일 12시 왕십리 6번 출구 → 엔티티, ERD 설계

• 주제 관련

  • 만들어주세요 - 맞춤 제작 플랫폼

    • 필요성

      • 맞춤 케이크와 같은 수제 제품 제작 시 가격 정보들을 업체마다 찾아봐야하는 불편함

    • 기능

      • 서비스 내에서 고객이 원하는 시안을 표현할 수 있음
      • 반경 몇 km 이내 거리를 설정하고 그 안에 등록된 업체들에게 알람이 감
      • 고객이 보내준 시안 + 요구사항에 업체들이 가능한 가격, 일정 등으로 응답
      • 고객이 업체 선택

    • 장점

      • 사는 곳 근처의 업체를 찾아줘 픽업 용이
      • +@

    • 회원/비회원/관리자

    • 채팅

    • 예약

    • 결제

  • 편의점 할인 가격 비교 서비스

    • 필요성
      • 특정 제품 ex) 제로콜라 을 자주 사는데 편의점마다 할인 정책이 달라서 한눈에 보고 싶다.
      • 현재도 비교할 수 있지만, 각 편의점 어플을 찾아서 봐야함

  • 우산 아이디어 긍정적 검토중 → 프론트하고 논의 필요

    • 결제
    • 지도
    • 우산 대여 (동시성)
    • 리뷰

  • 미술 관련학과 학생들 작품 처치 관련 서비스

    • 결제
    • 채팅
    • 동시성

  • 중고가 적절 판별

    • 회원 관리
    • 상품 - 등록, 수정, 삭제
    • 추천 수(동시성)
    • 채팅
    • 가격 추이 그래프

• 프로젝트 사용 기술, 툴 정하기

  • Java 17
    • record 사용 가능
    • stream 관련 더 간결한 메소드 존재.
  • SpringBoot 2.7.7
    • 3.X.X 버전은 reference가 부족함.
  • DB : MySQL 8.0
    • 팀원들 모두가 공통적으로 사용할 수 있는 DB
  • Test DB : MySql
    • 도커 이용
    • 운영환경과 DB 를 같게한다.
  • TEST Framework: JUnit5, Mockito
  • Build Tool : Gradle
    • Maven에 비해서 dependency 파일의 가독성이 너무 좋음.
  • API 문서화 Tool : RestDocs
    • 비즈니스와 API 문서화 코드의 분리를 위해서 Swagger가 아닌 RestDocs.

• 코드 컨벤션

  • rest api 컨벤션 → 프엔 협의 필요
  • 예외 컨벤션 → 프엔 협의 필요
  • DTO
    • 형식: record 로 관리한다. → Builder도 정해야할 듯
    • 네이밍 : 끝에 DTO 빼고 UserCreateRequest, UserCreateResponse 와 같이 작성한다.
      • 책임이 다르다면 필드와 검증 내용이 같더라도 분리한다.
    • DTO ↔ Entity 변환 위치 : Mapper 사용
      • Entity → DTO 로직을 엔티티에 두면 엔티티가 DTO 의 변화에 영향을 받게 되고 엔티티 로직이 비대해짐.
      • Entity → DTO 로직을 DTO 에서 static 메서드로 하면 코드의 통일성이 흐트러진다.
      • 그러므로 Mapper 를 사용하기로 함.
  • 검증
    • 올바른 객체 생성을 위한 검증은 Bean Validation 으로 입력 DTO + 엔티티 생성자에서한다.
    • 서비스의 정책 상 필요한 로직을 검증하는 것은 서비스 단에서 한다.