개발 환경, Validation, DTO 규칙, 프론트 언어 변경 사항

🔥멘토님 말씀 체크 리스트

• ☁️
  2022.06.16

어제의 진행상황

• API 설계 작성 및 시퀀스 다이어그램 작성

• ERD 수정

• 패키지구조 설정(혜빈님)
도메인 // global 패키지도 따로 가져가야할지?
• exception // 도메인별로 exception 패키지를 또 따로 가져가야하나?
• security // member만 사용하는 기능이라 어디에 둘지 생각을 해봐야한다.
• configuration
post
• controller
• service
• domain
• Post
• PostRepository
• dto
• user
• comment
• commentLike
• follow
• likePost
• likeComment
• image

url path 형식 정하기

• prefix
• /api/v1/posts
• /api/posts(결정)

Reponse 형식 정하기

• HttpStatus 코드 응답값에 따로 담아줄 것인가?
• 일단 빼는걸로 !

예외처리 형식 정하기

🔖 오늘의 이야기 해볼 점

• 뼈대 코드 작성완료(진형님)

• 시간이 많이 부족하다 주말을 활용하자
• 주말을 어떻게 활용할까? -
• 1시부터 ~ 3시 (필요하면 저녁까지)
• 동운님 - 1시~6시
• 병연님 -
• 혜빈님 -
• 형욱님 -

• 시퀀스 다이어그램 작성 완료여부 확인하기

• ERD 작성 완료여부 확인하기

• Swagger와 RestDocs의 어떤 차이가 있는지와 사용법 조사하기
• 병연님 !

• 지라 어느정도 구성이 완료되었는지 체크하기(이슈관리 관해서)
• 스프린트 시작하기
• 워크플로우 구성하기

• 패키지 구조에 대해서 다시 이야기 나눠보기

개발환경 문서화

개발환경

• springboot - 2.7.0

• Java - 17

• Build - Gradle

• DB - MySQL

• ORM - JPA

• IDEA - IntelliJ

유지보수

• 코드 정적 분석 : sonarqube

협업 툴 및 관리

• API 문서화 : Swagger or RestDoc (미정)

• 이슈 관리 : Jira

• 커뮤니케이션 : Slack

• 형상관리 : GitHub

Validaion 규칙 정하기 미정

• 동운님
• Service, Entity
• 잭슨님 말씀해주신 부분처럼 Web을 못 믿는다는 전제 서비스에서 다른 서비스를 호출했을 때를 생각하면 Service에서 필요하다고 생각됨 필요한 부분이 있다면 부분적으로 Controller에서 해도 된다고 생각합니다.
결론 : Entity > Service > Controller

• 병연님
• 검증 범위 : entity, controller(dto)
• dto에 notnull, notBlank, pattern (무거운 작업)들만 validation 설정
• entity에 fix된 정책 기반으로 확실히 validation 설정한다.

• 형욱님
• Controller, Entity 에서 검증하도록 하면 좋을 것 같습니다.
• DTO 에서는 느슨하게(빈 문자열, null 체크)
• Entity는 핵심 도메인이기 때문에 강하게
• Service 에서도 해야한다면? 모든 레이어에서 다 해야한다고 생각이 드는 것 같습니다.

• 진형님
• 3개는 너무많고 1개는 너무 적다
• Controller, Entity 또는 Service, Entity (Entity는 무조건)
• 핵심 비즈니스 로직에서 validation을 하는게 맞다. 그러므로 Service, Entity가 좋아보인다.
• 하지만 Service에서 validation하는 것은 아직 안해봤고 비즈니스로직이 어지러워 보일 수 있을 것 같아 절충안으로 Controller, Entity가 괜찮아 보인다.
• 그렇게 어렵지 않다면 Service, Entity가 가장 확실해 보인다.
• Controller에서 한다면 Controller에서는 비교적 느슨한, Entity에서는 강력한 Validation (멘토님 말씀)
• Entity → Service → Controller

• 혜빈님
• controller + entity
• service 끼리 관계가 많을 것 같으니까 service에도 하는게 맞나 ?
⇒ controller 에서도 꽉 잡아서 해줘야 할 듯

결론

DTO 규칙 정하기

• 동운님
• Service
• 매개변수 : Dto로 받는게 맞는건가….? 잘 모르겠음. 매개변수를 별개로 가져갈수 있는 부분은 가져가는 걸로… 최대 : 3
• 반환값 : Service에서 Dto 변환 후 반환
 
• Dto 관리
• Inner Class로 묶을 수 있다면 묶는게 좋다고 생각합니다.
 
• 네이밍은…
• 요청: Create, Update, Delete Request….
• 반환 : Response 하나로 공통화 시켜놓고.. 하고 나서 별도로 필요한게 있으면 별도 네이밍 지정해서 생성

• 병연님
• Dto domain 별 static inner record, class 관리

• staic nested dto guide
1. record로 불변 객체를 보장하는게 1순위
2. 어쩔 수 없는 상황이면 static inner class

• 예시

• 형욱님
• DTO 허용범위
• Controller 아니면 Service 에서 끊으면 될 것 같습니다.
• DTO 네이밍
• EntityName + Request or Response (static)
• Create, Update, , …
• EntityName + Create, Update …
• Request에 관해서는 Create, Update 를 따로 만들어서 관리하고 Response만 하나로 작성해서 가져가도 좋을 것 같습니다.

• 진형님
• Service에서 엔티티 끊는거 선호합니다.
• XXXRequest 내부에 이너 스태틱 클래스로 CreateRequest, UpdateRequest 레코드로 작성하는것 선호합니다.
• 예시 →
• PostRequest.UpdateRequest 게시물 업데이트 요청
• PostResponse.UpdateResponse 게시물 업데이트 응답
• PostRequest 게시물 작성 요청
• PostResponse 게시물 작성 응답
• 네이밍 Create,Update,Delete XXX Request,Response

• 혜빈님
• service 까지만 entity 사용
• XXXRequest
• Create, Update …
• XXXResponse
• PostResponse
• 이너 record 사용해서 PostDto.CreateRequest ();

😱 게시글 시퀀스 다이어그램 피드백 & 의문사항

• 게시글 조회
• 댓글, 댓글 개수, 좋아요 개수까지 함께 조회되도록

• 게시글 상세조회
• 댓글 페이징까지…? 🤔

공동으로 티켓을 진행할 수 있나요?

멘토님께 여쭤 볼 사항

1. DTO 네이밍에 관하여
1. PostRequest 최상단에 innerclass 로 관리를 할 경우 Create or CreateRequest 어떤걸 해야할지
 

2. 게시글 시퀀스 다이어그램에 관해서
• Comment도 Post를 쓰고, Post도 Comment를 사용하는 순환 문제가 발생
• 이걸 게시글이 주체로 모든 댓글 요청을 Post로 하는게 좋은지…?
• 진형 : 그냥 하나의 서비스에서 여러 Repository 사용하는게 편리해 보인다~
 

📌 프론트 개발환경 React → Thymeleaf 로 변경

• 백엔드 전 인원이 할 수 있는 걸로 하기 위함 → 프론트 단을 고려하면서 개발 할 수 있도록 하기 위함 (✨ 멘토님의 조언)

• CORS 설정은 어떻게? 🤔 리액트로 임의로 GET POST 통신만 할 수 있는 더미 프로젝트 생성후에 백엔드 CORS 설정 하기!