아키텍쳐

• 헥사고날

  • 잘 쓰는거 아니면 개구림
  • 러닝커브 높음

• 4-layered

  • 애매함 뭔가….. 도메인 별 검증 객체를 따로 빼는 걸 생각해봐야할 듯
  • 3 layered 아키텍쳐와 비슷? 헥사고날과 같이 쓰면 시너지?
  • 코드 보면 이해갈 것 같음
  • 튜터님 말씀

  서로의 의존도를 낮추고 싶다는게 핵심!
  서비스 입장에서 봤을 때 다양한 클래스들을 의존해야 할 수도 있음
  의존도 높을수록 변경에 예민해지고 테스트 코드 불리해짐
  인터페이스로 풀고, 의존 방향 단방향
  

  • 우선 이거 써보는 방향으로 ㄱㄱ

• 기존

  • 외부 리소스를 사용하는 부분이 많아서 적절하지 않은 듯

기능 명세

• 알고리즘 문제 크롤러
  • 파이썬 사용 (예정)
  • 사이트 구조가 규칙적이지 않음…

컨벤션

• 엔티티 클래스, 테이블 네이밍
  • 둘 다 단수형으로 표현 (user 제외)
  • ex) User-users, Problem-problem, UserProblemStatus-user_problem_status
  • 양방향 맵핑 최대한 피하기
• 네이버 컨벤션 사용
  • IDE에 적용 가능
  • https://bestinu.tistory.com/64
• LF vs CRLF
  • 프로젝트 규모가 커지면 파일 크기 차이가 유의미하다고 함 (CRLF 채택)
• JPQL vs QueryDSL → 필요할 때만 QueryDSL 쓰기
• throw 어디서 할 건지? 서비스 vs 레퍼지토리
  • 승우님 의견 채택 → BaseRepository (findById 등은 repo), 검증은 service
• DTO 팩토리 메서드
  • from : 객체를 DTO로 변환
  • of : 여러 파라미터를 받아서 DTO로 변환
• DTO → record 사용
• 이미지? S3 PRESIGNED URL 방식으로

@NoRepositoryBean
public interface BaseRepository<T, ID> extends JpaRepository<T, ID> {

    default T findByIdOrElseThrow(ID id) {
        return findById(id).orElseThrow(() ->
                new BusinessException(ResultCode.NOT_FOUND, "해당 Entity를 찾을 수 없습니다. id = " + id)
        );
    }

}

common —

├── presentation              111111                  <---- 표현 계층