프로젝트 계획

만든 이유

• 유튜브 쇼츠 볼 시간에 쇼츠 형식 개발 지식을 공부하기 위해서
• 공부했던 내용을 복습하지 않으면 까먹기 때문에 편리하게 접근하기 위해서
• 백준과 프로그래머스에서 푼 문제들중에서 복습하기 위해서

 

목표

과거 프로젝트에서는 개발에 필요한 내용을 AI 검색이나 구글링으로 대략 파악한 뒤

코드를 복붙해 수정하면서 동작하도록 만드는 방식으로 진행했다

 

이번 프로젝트에서는 복붙 없이 시간이 오래 걸리더라도 학습을 목적으로 모든 코드를 직접 타이핑하며 진행할 계획이다

그 과정에서 발생하는 다양한 오류를 직접 마주하고 원인을 분석해 기록하며 이해도를 높이고자 한다

AI 시대에 다소 비효율적인 방식일 수도 있지만 개념을 제대로 익혀두는 경험이 중요하다고 생각한다

 

1차 목표

• 메인 화면에서 면접 질문들 숏폼으로 보여주기
• 알고리즘 푼 문제
  • 알고리즘 read 기능
  • 알고리즘 풀었을 경우에 푼 횟수 증가되도록 update 기능
  • 알고리즘 푼 문제 create 기능
  • 알고리즘 푼 문제 delete 기능

2차 목표

• api response 규칙 공통으로 처리
• 엑셀 업로드로 알고리즘 푼 문제 추가

리팩토링때

• 하나의 도메인(Request)에 관련된 DTO들을 외부 클래스 하나로 묶고 내부 정적 클래스(record)로 역할별 분리하는 구조(
  • record로 만든다.

 

규칙

DTO

- 요청dto (도메인 + 행위 + 역할)

  - ex) AlgorithmCreateRequest

- 응답dto (도메인 + 조건 + 역할)

  - ex) AlgorithmListResponse

 

 Layer별 메서드 명칭

Controller ~ Service Layer의 메서드 명칭과 Repository Layer의 메서드 명칭을 다르게 작성하여

비즈니스 로직이 동작하는 메서드인지 저장소에 Accesss 하기위한 기능을 제공하는 메서드인지 구별

 

 

아래 내용은 공부하고 적용

DTO 변환은 정적 팩토리 메서드를 사용

• 인자가 하나인 경우 request → from()
• 인자가 여럿인 경우 request, pageable → of()

Validation

• 검증은 표현 계층에서 한 번, 도메인 모델에서 한 번
• 클라이언트 ↔ 컨트롤러DTO(requestDto)에서는 단순한 필드 검증을 수행한다.
• 해당 검증은 bean validation

• 도메인 모델에서는 단순한 필드 검증과 비즈니스 규칙 검증을 포함해서 수행한다.
• 도메인 검증은 직접 작성

• 컨트롤러 ↔ 서비스DTO(commandDTO)에서는 검증을 수행하지 않는다.

예외

• Custom Exception을 정의하여 사용한다.

• 엔티티 없음: NotFound-Domain-Exception
• ex) NotFoundUserException

• 검증 예외: Invalid-Domain-Exception
• ex) InvalidUserException

 

(?) - 이건 아직 모르겠네

- dto나 entity의 숫자 타입은 Integer로 통일 

  - Integer 클래스 내부 메서드를 사용할 경우가 있을수도 있어서

  - 값을 넣지 않았을 때 기본값 0이 아닌 null값을 사용하기 위해서

 

 

참고)

https://oliveyoung.tech/2023-12-05/partner-platform-code-convention/

https://blog.naver.com/steve6133/223205900459