HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
♥️
2기 최종 프로젝트 팀별 공간
/
💸
10원모아10조❗️
/
07월 19일

07월 19일

주제
주로 컨벤션 및 제안?
작성자
Yanju
주차
0주차
 
메모
  • 내일 마르코한테 CD 조언 + CD 뭐쓸지 어떻게할지(당장 급한 건 아님)
  • Validation을 섞어서 쓰는것도 괜찮은지
  • 윌리엄이랑 루체는 마르코팀 코드 컨벤션 확인해보고 내일 같이 논의
    • https://github.com/prgrms-be-devcourse/BE-02-MarBox#-convention
  • 패키지
  • 일정
    • 이번주 일요일까지 어느정도까지 진척도…?
    •  
  • front end 테스트용 서버와 데이터베이스 운용 방법(prod, dev 서버 따로 관리??)

코드 구현 시 디테일한 부분 Author : william

  • Validation 방법
    • guava — https://www.baeldung.com/guava-preconditions
    • Bean Validation
    • controller, service, entity 어디에서 집중해서 Validation 할지?
      • 도메인에서는 생성자에서 validation 하는 식으로 하는 편이 좋을것 같다
      • 전체 레이어에서
  • 롬복 사용?
    • 빌더랑, noargs, getter, RequiredArgs
  • 제안하고 싶은 것
    • Service는 Interface 만들고 Impl 식으로 구현하기
      • 메서드를 구분하는것이 목적이라면, 주석으로 충분할 듯.
      • Impl 패턴은 안티 패턴
    • Dto 클래스 만들 때, 클래스 안에 public static class로 만드는 방식
      • Dto와 Entity를 분리해야하는 이유 찾아보기
    • Dto ↔ Entity, Converter 클래스 도입 (?) → 이것도 찾아보고 다시 이슈화
    • Service에서 엔티티를 반환, 웹 모델을 반환 → 웹 모델
    • ErrorCode 만들 때, 도메인 별로 NotFound일 때 메시지는 비슷하다고 생각함(이런 방법은 어떤지..)
      • public class NotFoundException extends AircncRuntimeException { public NotFoundException(Class<?> clazz) { super(clazz.getSimpleName() + "(이)가 존재하지 않습니다"); } public NotFoundException(Class<?> clazz, String arg) { super(arg + "에 해당하는 " + clazz.getSimpleName() + "(이)가 존재하지 않습니다"); } }
 
🔏
Luce 궁금증 및 제안
 
[ 목차 ]
1. 회의 안건 2. 회의 내용 3. 결정사항 4. 다음 회의 안건
 

1. 회의 안건


  1. CI CD 결정
  1. 메모에 적은 내용
 

2. 회의 내용


  1. CI CD
      • CD는 S3, code deploy
      • 그리고 조언을 구한다면 도커 or s3 둘 중 하나로 마르코한테 의견 물어보기
  1. 깃헙 플로우 브랜치 전략
      • 무중단 배포를 하기에 적합한 브랜치 전략인 것같다. (얀주 의견)
      • 배포를 고려한다면 디벨롭이 필요하다고 들었는데 공부좀 할게여…(루체..)
  1. Service는 인터페이스 → 구현체로 Impl
      • 인터페이스로 한 눈에 제공하는 메소드를 파악할 수 있다. (윌리엄)
        • CQRS 의견을 듣고 생각을했다.
      • 서비스를 인터페이스로 쓸 때는 DI를 사용하는것으로 안다. (캉테)
        • 의미를 파악하는 용도로는 주석만 잘 달아놓으면 인터페이스를 사용하지 않아도 될 것 같다.
      • Service를 인터페이스로 분리하려면 레이어 구분이 깔끔해야한다. (루체)
        • 하지만 어렵다.
        • 관리가 더 어려워진다.
  1. Dto 클래스
      • inner 클래스로 관리 (루쳬)
        • 컨버터는 응집도가 안 좋고 관리할 클래스가 더 늘어난다.
        • Dto 클래스 안에서 DtoToEntity, EntityToDto 변경 코드 포함
  1. Lombok
      • getter, setter는 커스텀해서 사용해야한다.
      • 컬렉션 문제 예방
  1. Validation
      • 필요한 모든 부분에서 valid 했다 (캉테)
        • 한 곳에서만 valid 하는게 안티패턴
      • BeanValidation 사용, 컨트롤러에서도 validation 테스트, DTO에서만 BeanValidation 사용
      • 도메인에서는 assert를 사용 (루체)
        • 스프링에서 그렇게 사용하니까 우리도 그렇게 사용했다.
      • 필드에 BeanValidation을 사용하면 깔끔하게 확인이 안된다. (다른 어노테이션이 많다)
        • BeanValidation을 모르는 입장에서도 이해할 수 있다.
      • 도메인에서 guava 사용 (윌리엄)
  1. 에러 코드
      • 애매하게 에러 메시지를 보내야 해커의 공격을 피한다.
      • 루체의 의견을 많이 따른다.
        • 제가 죄송합니다..(루체…)
 

3. 결정사항


  1. CI CD는 캉테 의견을 따라가는 쪽으로 (마르코 의견을 듣고 변경할 수도 있다)
  1. Service는 interface 없이 진행
  1. Dto와 Converter를 분리하는 이유 찾기
  1. 롬복사용
      • 빌더랑, noargs, getter, RequiredArgs
 

4. 다음 회의 안건

  • 상태 코드를 미리 정의하자
  • 자산 보다는 백엔드가 보여줄 수 있는 다른 역량
    • 퀘스트를 이용
  • 회원 탈퇴시 기존 회원의 정보 보존 유무
    • 6개월 이내 다시 회원가입 했을 시 백업이 가능하다