Lets go show

 현재 진행하고 있는 프로젝트에서 최대한 스프링에 대해 공부했던 내용들을 최대한 담아보려고 하고 배운다는 생각으로 프로젝트를 진행 중에 있다.  우리 프로젝트는 계획형(J)이 아닌 즉흥형(P)이지만 계획을 세워 체계적으로 살고자 하는 사람들을 타겟으로 일정을 대신 세워주는 프로그램을 만들고 있다. 

즉 우리 핵심 비즈니스 로직이 일정과 관련되어 구현되어 있고, 좀 더 체계적이고 객체지향 관점에 맞게 설계하려고 노력했다. 그렇기 때문에 어플리케이션 레벨에서 다형성을 적용할 수 있는, 상속관계 매핑을 고려해서 적용해서 설계했다.

우리 ERD의 일부는 다음과 같다. 

먼저 데이터베이스 레벨관점에서는 상속관계 매핑 전략 중 더 정규화된 형태의 데이터관리를 위해 Join  전략을 선택하여 구현했고, 각각의 공통필드와 개별적으로 필요한 필드를 분리하여 테이블 설계를 했다. 

 어플리케이션 레벨의 관점에서는 흔히 사용하는 BaseEntity 에 공통필드를 정의하고 상속받는것 처럼 우리 프로젝트에 존재하는 3가지 유형의 일정에 대해서도 공통적으로 처리할 수 있는 필드에 대해서는 추상클래스를 사용하면 구조적으로 이점을 가져갈 수 있지 않을까 라고 생각을 했다. 

하지만 막상 구현을 해보니 내가 생각한 관점보다는 조금 더 깊게 고민해봐야할 요소들이 꽤 존재했다.

추상메서드를 설계하고 , 인터페이스를 설계하는 이유는 다형성을 적용했을 때의 이점 때문이라고 생각을 한다. 다형성을 적용하기 위해서는 정의된 함수의 시그니처를 따르는 함수를 자식클래스에서 구현해야하는데, 우리 프로젝트에서는 일단 첫번째로 각각의 엔티티를 살펴보면 자식클래스들이 가지고 있는 필드들이 다 다른 상황에서 하나의 시그니처를 가지고 각 일정의 유형에 맞는 로직을 만들기가 구조적으로 어려웠다. 

일정 수정, 일정 삭제와 같은 API 구현할 때 공통 수정 엔드포인트 1개, 공통 삭제 엔드포인트 1개를 구현한다고 했을 때, 

예를 들면 다음과 같은 방향으로 구현하고 싶었다 

- PUT Mapping /Schedule/{id}

    - Schedule 엔티티에 update 메서드를 선언하고 각각의 일정에서 update 메서드를 구현 

    - schedule service -> id와 매핑되는 일정 조회 

    - schedule service ->  각 유형의 일정 수정에 쓰이는 공통 dto을 schedule.update 메서드의 파라미터로 넘겨서 수정 

    - dirty checking  

    - schedule controller -> scheduleService.update() 호출 

    - schedule controller -> scheduleService.findById() 호출

    - response dto 반환 

하지만 각 유형의 일정마다 맺고 있는 연관관계가 다르고 필드도 달라서 하나의 공통 Dto를 받는 시그니처의 메서드를 구현한다는 것이 쉽지않았다.  예를 들어서 , 일정을 수정한다고 했을 때 일반일정은 totalAmount, bufferTime, 슈퍼클래스의 필드들, 더 나아가 일반일정과 연관관계에 있는 다른 테이블의 정보까지 함께 수정되어야 하고  변동일정은 일정의 시작시간과 종료시간, 슈퍼클래스의 필드를 수정해야 했다. 즉 하나의 추상메서드를 뽑아서 구현하기에는 어려움이 존재했고 각각의 일정에 맞는 일정 수정 메서드를 구현하는게 맞다고 생각했다. 

이 과정에서 들었던 생각을 나열해보면 

 각각의 일정에 맞는 로직을 구현하기 위해 각각의 메서드를 만들어야 한다면 추상클래스를 제대로 사용하고 있는것이 맞을까..?

테이블 상속관계를 유지하는 것이 맞을까 ..?  

일반일정, 변동일정, 고정일정이 일정이라는 공통된 속성과 기능을 가진다고 생각했지만 상속관계를 가지지 않는 개별적인 엔티티의 관점으로 보는게 맞는게 아닐까 ..? 

 결론적으로 현재 구조에서 추상클래스를 제대로 활용하지 못하고 있기 때문에 설계된 테이블 상속관계는 비효율적이라고 생각했다.

또한 어플리케이션 레벨에서의 구조적인 부분도 문제지만, 일정하나를 조회하더라도 일정테이블 3개를 조인 해야하는 DB 관점에서도 봤을 때 일정이 몇백만개 단위로 존재한다고 가정하면 코스트가 작지 않을 것이라고 예상한다. 

아마도 추후에 테이블 구조를 변경하게 될 것 같다.

상속관계 매핑은 신중히 고민하자 !!!!!!!!!

프로젝트를 빌드했을 때 build/generated/sources/annotationProcessor/java/main/.... 에 Q파일들이 생성되는데요, 

소스코드를 찾는 과정에서 Q파일들의 코드를 인식하지 못하는 문제가 발생해서 source 세팅을 build.gradle 파일에 추가 해주었습니다.

아마 generated되는 Q파일의 경로를 /src/main/java 하위 경로에 생성되게 설정을 해두면 sourceSets 설정없이도 아마 인식할 것 같습니다. 

1. build.gradle 작성 

 - dependencies에 querydsl관련 설정 추가

 - sourceSets 에  "$projectDir/build/generated" 경로 추가 

2. gradle clean 후 다시 빌드 

build.gradle 공유 

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-devtools'
    implementation 'org.springframework.boot:spring-boot-starter-validation'
    compileOnly 'org.projectlombok:lombok'
    runtimeOnly 'com.h2database:h2'
    annotationProcessor 'org.projectlombok:lombok'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'

    //Querydsl 추가
    implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
    annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta"
    annotationProcessor("jakarta.persistence:jakarta.persistence-api") // java.lang.NoClassDefFoundError(javax.annotation.Entity) 발생 대응
    annotationProcessor("jakarta.annotation:jakarta.annotation-api") // java.lang.NoClassDefFoundError (javax.annotation.Generated) 발생 대응

}

sourceSets {
    main {
        java {
            srcDirs = ["$projectDir/src/main/java", "$projectDir/build/generated"]
        }
    }
}

tasks.named('test') {
    useJUnitPlatform()
}

clean {
    delete file('build/generated')
}