Home

프로젝트 기술 목표

• DDD를 이용해서 코드들의 응집도를 높이고 결합도를 낮출 것입니다.
• 객체지향적인 코드를 작성하고 클린 코드를 작성할 것입니다.
• 코드를 작성하자마자 테스트를 작성할 것 입니다.
• 프로젝트를 진행하면서 했던 고민 사항들 이슈에 기록할 것입니다.(concern 태그가 붙어 있습니다.)

프로젝트 이슈 모음

DDD

• 애그리게잇을 어떻게 구성해야 할까?
• 애그리게잇 양방향 의존성 제거
• 하나의 DB 테이블에 여러 개의 엔티티 매핑
• 하나의 바운디드 컨텍스트를 둘로 나눠야 하는 지에 대한 고민
• 애플리케이션 레이어의 클래스들을 역할에 맞게 분리

객체지향

• PrePostService를 통한 복잡도 해결 과정
• 전략 패턴을 통해 외래키 제약 조건을 제거하는 로직 구현
• 변경 가능성이 있는 서비스 레이어에 인터페이스 적용
• 컨트롤러에서 요청 받은 DTO를 서비스에서도 사용해도 될까?
• TimeTable에 유효성 검증을 담당하는 객체 생성

JPA

• JPA를 사용하지 않고 JDBC를 통해 테이블을 직접 조회
• 프록시 객체로 인해 발생한 문제
• 테스트에서 @Transactional 없애게 된 이유
• osiv 설정 false로 변경
• default_batch_fetch_size를 추가 과정
• 영속성 컨텍스트와 JPQL의 동작 착각

글로벌 예외 처리

• ResponseEntityExceptionHandler 클래스 중 몇 가지 메서드만 오버라이드한 이유
• DB에서 에러가 발생했을 때, 사용자에게 알려줘야 하는 에러는 무엇일까?

성능

• DB 인덱스 정리
• DB 페이징
• CalendarProviderSerice를 생성한 이유
• ReviewDate를 생성한 이유
• ReviewCycle에 제1정규화를 적용하지 않은 이유

기타

• 프로젝트의 컨트롤러들 url 수정
• MDC에 쿼리 카운터와 API 총 소요 시간 추가
• HTTP GET 메서드를 사용해서 리소스를 생성한 부분, 생성 기능과 조회 기능으로 나눔
• 태그 검색어 자동 완성 기능
• 도메인의 조회 시 유저(소유자) 검증 기능을 만들 때, 고려 사항

중요도가 떨어지는 이슈

세부 내용

도메인

• Status를 TaskStatus와 SubTaskStatus로 나눈 이유, DTO에 있던 toEntity() 제거 이유
• 캘린더 -> Goal, Goal -> SubGoal 이름 변경 기능이 있는 이유
• 캘린더에 목표 추가 기능이 있는 이유
• Goal에 CalendarGoal 삭제 기능이 있는 이유
• 복습 기능을 위해 ReviewTask를 만든 이유
• timetable 패키지를 daily_schedule 패키지로 옮긴 이유
• review 패키지에서 애그리게잇의 양방향 의존성 제거
• Goal에서 CalendarGoal를 삭제하는 기능을 없앤 이유
• 메모에 태그를 추가할 때 갯수 제한을 둠

MySQL

• LearningTime에 있는 task 외래키 연관관계 제거 (전략 패턴을 통해 추후에 리팩토링함)
• MySQL DATE -> TIMESTAMP 타입으로 변경한 이유
• 캘린더 조회 시 쿼리 발생 갯수
• daily_schedule 테이블과 DailyChecklist 엔티티에 총 점수와 성취도 필드 추가

기타

• @Valid, @Validated 테스트 작성
• DTO에서 복습 주기를 받을 때, 중복된 값을 없애기 위해 Set 자료 구조를 사용함

취소된 기능

• 컨트롤러에서 잘못 사용된 애노테이션 수정
• DataHelper에서 dto 생성 기능 삭제
• 외부에서 발생한 에러를 담당하는 NotValidExternalRequestException 생성
• response dto에 애노테이션 삭제함
• 캘린더 패키지에서 잘못 사용된 url 및 http method 수정
• NotValidExternalRequestException 삭제
• 모든 DTO들을 서비스 레이어로 옮김 (취소됨)