레이어 중심으로 구분하여 책임 분리를 명확히 해줬고,
기존 레이어드 아키텍처의 한계인 상위 계층에서 하위 계층으로 의존성이 발생하여 내부가 변경되면 코드 전체가 수정되어야하는 문제점이 있다.
이를 해결하기 위해 클린 아키텍처 개념을 추가하여 레이어드 구조는 유지하되, 중심을 비즈니스 로직인 도메인 계층으로 설정해줬다.
도메인(서비스)이 직접 구현체를 호출하는 (repository) 대신 추상화에 의존하게 하여(repository) 의존성 분리를 해주었다.(repositoryImpl)
파사드 디자인 패턴을 사용하여 도메인 별로 각각 분리된 서비스 로직을 한 곳에 모아 동작되도록 하였다.
컨트롤러는 서브 시스템 동작을 몰라도 파사드 인터페이스만 호출시켜 사용하면 되는 이점이 있다.
- 사용자 ID와 특강 ID를 입력받아 특강 정보를 조회한 후, 해당 특강에 대한 신청을 처리한다.
- 필요 테이블
- 사용자 테이블
- 특강 테이블
- 특강 신청 테이블
- 입력받은 날짜를 기분으로 특강 테이블에서 해당 날짜에 해당하는 신청 가능한 특강 목록을 조회한다.
- 데이터 성능 최적화
- applicant_number(신청 인원): 신청된 인원을 실시간으로 조회하지 않고 저장하여 계산 비용 절감할 수 있다.
- is_available(신청 가능 여부): 신청 가능한 상태('Y')인 특강만 조회 가능하도록 필터링 할 수 있다.
- 효율적인 데이터 처리
- 매번 특강 신청 테이블에서 신청 인원을 계산하지 않아 연산 성능 향상된다.
- 특강 신청 테이블에서 상태값이 'COMPLETED'인 신청 목록만 조회한다.
- status 컬럼 추가:
- 특강 신청 상태를 구분: 'COMPLETED'(신청 완료), 'CANCELED'(신청 취소)
- 데이터 성능 최적화
- 특강 신청 테이블에 관련 특강 정보를 함께 저장 : 조인 연산을 최소화하여 조회 성능 향상된다.
- 과거 신청 데이터를 스냅샷으로 저장: 특강 신청 시점의 정보를 보존하여 데이터 일관성 유지할 수 있다.
- Users ↔ Registrations
- 일대다 관계 (1명의 사용자가 여러 특강에 신청가능)
- Lectures ↔ Registrations
- 일대다 관계 (1개의 특강에 여러 사용자가 신청가능)
