TIL 66 [ Spring 최종 프로젝트 ( Day 2 ) - ERD설계, 컨벤션/규칙, 4-Layer 아키텍처 ]

설계가 이렇게 힘든 작업인 줄 몰랐다..

프로젝트 규모가 큰 만큼 확실히 정기적으로 팀 회의가 자주 이루어지는 것 같다.

✅ ERD 설계

최종적으로 ERD가 완성되었다. ( 개발하다가 수정될 수 있음. )

 

완성 되기전에 피드백을 다시 두 튜터님에게 찾아가서 확인 절차를 밟았다.

관계 선 정리가 우선적으로 선이 겹쳐져 있지 않아야한다는 점이 매우 컷다. 실제로 개발을 할때 헷갈릴수 있기 때문이다. 그래서 수정 작업에 들어갔다.

soft delete 또한 boolean 타입으로 하였는데, 삭제 시간을 필요로 하는 경우도 많아서 고려해보기도 하였다.

 

채점 방식에 대해서도 많은 고민이 와갔는데, 프로그래머스가 좀더 특별한 방식으로 진행되었던 점이다. 다른 코테 사이트들은 표준 입출력으로 유저가 직접 입력하고, 하나로 퉁쳐서 성공/실패 (백준)으로 구분하는 방식으로 가져갔다.

 

첫날에 고도화까지 미리 설계를 해버려서 이슈가 좀 있었지만, 그래도 고도화 까지 미리 설계를 해놓은 느낌이 들어서 시간이 좀 걸렸다는 점이 들었다.. 

 

그래서 선 정리와 정확하게 필드가 들어가 있는지 점검을 하는 시간을 가지게 되어서, 좀더 명확하게 보완된 ERD를 만들수 있었다.

✅ 컨벤션, 팀 규칙

git flow 전략은 main, dev, feat 그대로 하고, QA가 필요할시에 release로 하는 flow 전략을 정하였다.

엔티티 클래스, 테이블 네이밍

• 둘 다 단수형으로 표현 (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)
        );
    }

}

🔍 4-Layer 아키텍처

항상 프로젝트때 DDD구조만 해오다가, 처음으로 4-Layer 아키텍처 구조에 접하게 되었다.

이는 헥사고날 이라는 것을 포함하게되면 잘쓰는게 아니면 효과가 좋지 않다는 평이 있고, 러닝커브가 높다는 말이 있다.

 

그래서 기존에 3-Layer 아키텍쳐와 비슷하지만, 헥사고날과 같이쓰면 시너지 효과가 날 것이며, 직접 코드를 봐야 이해가 될것 같다라는 느낌이 든다. 한 팀원이 열심히 설명해주었지만, 실제로 해보고 경험을 하지 않아서 잘 감이 안잡히기는 한다..

 

그래서 다 같이 튜터님에게 찾아가서 이야기를 들어보았다.

이 아키텍처를 사용하는 이유는 서로의 의존도를 낮추고 싶다는게 가장 큰 핵심이 들어있는 것 같다고 보셨다.

서비스 입장에서 봤을 때 다양한 클래스들을 의존해야 할 수도 있고, 의존도가 높을 수록 변경에 예민해지고 테스트 코드가 불리함.

그래서 인터페이스로 풀고, 의존 방향 단방향으로 해야한다는 얘기를 해주셨다.

그래서 최종적으로 일단은 쓰는 방향으로 가게되었다. 

 

기존의 아키텍처 방식에서는 외부 리소스를 사용하는 부분이 많아서 적절하지 않다는 평이 있다..

Presentation - 사용자에게 노출되는 곳  ( Controller, converter )

Application - 시나리오 class  ( Dto, Repository, Service?? ) , + 인증/인가도 가능, 인터페이스

Domain - ( user, order, review ) ( Repository, entity )

infra  - DB(RDS), Cache 구현체

 

대체로 이러한 구조로 보이긴하는데 여기서 문제가 생겼다.

하나의 테이블에 하나의 패키지를 만들거면 그럼 100개의 테이블에 100개 패키지를 만들거냐 는 튜터님의 생각이 우리에게 논점으로 들어와서, 이를 해결하기 위해 Post에 해당하는 것들을 하나로 묶는 방식으로 가고 이를 community로 명하는 것처럼 관련 있는 것들을 하나로 묶는 방식으로 가져가게 되어 구조가 깨끗해지고 있다.

 

아직까지 해결되지 않은 것들이 몇몇게 있지만 점차 구조가 나아지고 있다.

설계가 생각보다 오래 걸리는 작업이라는걸 처음으로 깨닫게 되었다.

여태까지 거쳐온 프로젝트들은 목적이 뚜렷하고, 주제가 주어져서 기획과 설계부분에 많은 시간을 투자하지 않아서 그런지 최종 프로젝트에서는 많은 시간이 소요된 것 같았다. 내일도 파이팅 해야겠다.....