feat: api-repo 모듈과 Jooq 설정을 추가합니다

[belljun3395]

🎫 연관 이슈

resolved: #17

resolved: #31

💁‍♂️ PR 내용

• api-repo 모듈을 추가합니다.
• Jooq 설정을 추가합니다.

🙏 작업

api-repo 모듈을 추가합니다

api-repo 모듈을 추가하여 현재 프로젝트의 모듈 구성은 아래와 같습니다.

• api: API를 제공하고 비즈니스 로직을 수행합니다.
• api-repo: 데이터 베이스에 접속하고 쿼리를 질의합니다.
• data: 데이터 스키마를 정의합니다.

Jooq 설정을 추가합니다

Jooq + Flyway를 통해 Jooq 클래스를 만들기 위해서는 *.sql에 접근할 수 있어야 한다.

현재 *.sql 의 경우 data 모듈에 존재하여 api-repo에서는 접근할 수 없다는 문제가 있음.

copyDataMigration를 구현하여 data 모듈의 *.sql 파일을 복사하는 테스크를 정의하고 해당 테스크를 jooqCodegen과 compileKotlin 시점에 실행 될 수 있도록 설정하였습니다.

/** copy data migration */
tasks.create("copyDataMigration") {
    doLast {
        val root = rootDir
        val flyWayResourceDir = "/db/migration/entity"
        val dataMigrationDir = "$root/data/$flyWayResourceDir"
        File(dataMigrationDir).walkTopDown().forEach {
            if (it.isFile) {
                it.copyTo(
                    File("${project.projectDir}/src/main/resources$flyWayResourceDir/${it.name}"),
                    true
                )
            }
        }
    }
}

/** copy data migration before compile kotlin */
tasks.getByName("compileKotlin") {
    dependsOn("copyDataMigration")
}

/** jooq codegen after copy data migration */
tasks.getByName("jooqCodegen") {
    dependsOn("copyDataMigration")
}

🙈 PR 참고 사항

하다보니 PR 내용이 쫌 커졌는데

#32 의 경우 분리와 Jooq 테스트 코드 분리에 관한 의견이 궁금합니다!

=> 분리하였습니다!

참고링크

• https://www.jooq.org/doc/3.19/manual/getting-started/tutorials/jooq-with-flyway/

📸 스크린샷

FEW 프로젝트 모듈 설계 - 현 시점

FEW 프로젝트 모듈 설계 - 큰 틀

🤖 테스트 체크리스트

• 체크 미완료
• 체크 완료

[github-actions]

이 코드는 Gradle 빌드 파일의 일부로 보입니다. 세부 사항은 다음과 같습니다.

1. "bootJar" 작업이 비활성화되고, 대신 "jar" 작업이 활성화되었습니다. 이것은 기본적으로 스프링 부트 애플리케이션이 실행 가능한 JAR 파일 대신 일반 JAR를 생성하도록 설정하는 것입니다. 이 요구사항이 프로젝트와 일치하는지 확인해야 합니다.

2. 주요 의존성은 Spring Boot, MySQL Connector, Flyway 및 jOOQ로 구성되어 있습니다. 모든 의존성 버전이 DependencyVersion 클래스에 정의되어 있다는 점을 명심하세요. 이렇게 하면 중앙화된 위치에서 버전을 관리할 수 있습니다.

3. 데이터 마이그레이션 파일들이 복사되는 과정이 포함되어 있으며, "compileKotlin" 및 "jooqCodegen" 작업들은 "copyDataMigration" 작업에 의존하게 설정되어 있습니다. 컴파일 및 코드 생성을 시작하기 전에 마이그레이션 파일이 적절히 복사되었는지 확인하는 것은 좋습니다.

4. jOOQ 코드 생성기가 설정되어 있는데, 이는 DDLDatabase로서 스키마를 읽어온다고 가정하고 있습니다. "scripts" 프로퍼티는 모든 SQL 마이그레이션 스크립트 위치를 가리킵니다.

구체적인 문제에 대해 말씀드리자면, 코드는 전반적으로 깔끔하고 잘 주석처리되어 있습니다. 다만, 별도의 체크없이 파일을 바로 복사하는 copyDataMigration 태스크가 특정 시나리오에서 파일을 오버라이트할 가능성에 주의해야 합니다. 또한 살펴볼 필요가 있는 한 가지 사항은 "jooqCodegen" 작업이 정상적으로 실행되는지입니다. 또한 각 의존성 버전이 적절한지 확인해야 합니다.

[github-actions]

이 코드 작성법은 전반적으로 괜찮습니다. 다음과 같은 몇 가지 제안사항을 드릴 수 있습니다.

1. 테스트 설정: @BeforeEach 주석에 의해 각 테스트 전에 데이터베이스를 초기화하고 재 설정하는 것은 비효율적일 수 있습니다. 테스트 간섭을 최소화하려면 @Transactional 주석을 사용하고, 이어서 @Rollback 주석의 사용을 고려해보시기 바랍니다.

2. 논리적 삭제: softDelete 테스트에서는 DELETED_AT 필드를 현재날짜와 시간(LocalDateTime.now())으로 설정하고 있습니다. 일반적으로는 문제가 없지만, 시스템 시간에 따라 동작이 달라지기 때문에 테스트 결과가 일관성이 없을 수도 있습니다. 이를 해결하기 위하여 삭제한 시간값을 반환하거나 확인 가능한 방법을 고려해 보시기 바랍니다.

3. 하드 코딩된 값: 코드 내에서 EMAIL, TYPECD 등의 값을 직접 하드 코딩하는 대신, 외부 구성 파일에서 이러한 값을 불러올 수 있으면 좋습니다. 만약 여러 개의 테스트에서 똑같은 클래스를 사용하고 한 곳에서 값이 변경되면 다른 곳에서도 자동으로 변경되기 때문에 유지보수가 용이해집니다.

4. 테스트의 독립성 확보: 각 테스트 케이스는 변하지 않는 상태에서 작동하도록 하여 같은 테스트가 항상 같은 결과를 생성해야 합니다. @@

[github-actions]

이 코드 조각은 주로 로깅 레벨을 정의하는 설정 파일입니다. 여기에 대한 제 제안은 다음과 같습니다:

1. 각 로깅 레벨이 적절하게 설정되었는지 확인하세요. 너무 많은 디버그 로그를 작성하면 애플리케이션의 성능에 영향을 줄 수 있으며, 로그 파일의 크기가 커져 관리가 어려워질 수 있습니다.

2. 'com.few.api.repo', 'org.jooq', 'org.springframework.jdbc', 그리고 'org.testcontainers' 클래스 혹은 패키지가 실제로 프로젝트 내에 있는지 확인하세요.

3. 마지막으로, 파일의 마지막에 개행 문자("\n")를 추가했는지 확인하세요. 일부 도구는 이것이 없으면 제대로 작동하지 않거나 경고 메시지를 출력할 수 있습니다.

코드는 깔끔해 보이며, 위의 사항을 검토한 후 필요하다면 조정하면 됩니다.