인프런 커뮤니티 질문&답변

답변이 아직 없으신 동안 혼자 ReadOnly 이슈를 풀어보려고 @Transactional 옆에 ReadOnly = true를 지우고 테스트를 돌려도 아래 에러가 나길래 IntelliJ Preference랑 Project Structure 다 확인하고도 소용이 없고 그래서

* What went wrong:

Execution failed for task ':compileTestJava'.

> invalid source release: 11

무모하게 Cache를 전부 다 invalidate했다가 더 큰 문제가 생겼어요 ㅠ

이젠 ./gradlew build를 하면 아래 에러가 떠서

build.gradle에 아래 내용을 추가해야 해당 에러가 정리가 되네요..

그러고 다시 빌드 커맨드를 돌렸더니 맨 처음 invalid source release: 11 가 떠서 고치려고 보고 있습니다. Invalidate all caches가 아니라 그냥 Repaire IDE만 했으면 좋았을텐데 ㅠㅠ 방법이 없을까요?

안녕하세요! Suyeon님!!! 아이고~ 이렇게 정성스러운 질문 남겨주셔서 너무너무 감사드립니다!!! 🙇🙇 새해 연휴 이후 정신없이 일하고 퇴근하니~ 벌써 이 시간이네요..!! 조금 더 빠르게 답변 남겨드리지 못해 죄송합니다! 😭 빠르게 하나씩 말씀드려보도록 하겠습니다~!!!

[1. 트랜잭션 어노테이션의 의미]

네네 맞습니다!! 트랜잭션이란, 잘 찾아주신 것처럼, '모두 같이 성공하거나 모두 같이 실패해야 하는 작업의 단위'를 의미합니다! @Transactional 어노테이션을 붙이시게 되면, 해당 어노테이션이 붙은 함수 바깥에서 해당 함수가 호출될 때, 그 함수 안의 작업들은 모두 같이 성공하거나 모두 같이 실패하게 됩니다!!

class OrderService {

  @Transactional
  fun completePayment() {
    orderRepository.save(Order(..))
    pointRepository.save(Point(..))
    billingHistoryRepository.save(BillingHistory(..))
  }

}

예를 들어, 위의 OrderService 에서 completePayment 함수는 @Transactional 이 붙어 있기 때문에, 1) 주문 저장 2) 포인트 저장 3) 결제 기록 저장이 모두 같이 이루어지거나 셋 중 하나라도 실패하면 모두 다 같이 실패하게 됩니다!!

조금 어려운 내용이지만, 해당 어노테이션이 붙은 함수 바깥에서 함수가 호출되어야 한다는 조건은 https://cheese10yun.github.io/spring-transacion-same-bean/ 를 확인해보시면 좋습니다!! 😊

[2. Transaction과 JPA, Jdbi]

Suyeon님게서 질문 주셔서 Jdbi가 무엇인지 조금 찾아봤어요!! 6번 질문과도 관련이 있더라고요 ㅎㅎㅎ 제가 조금 찾아보았을 때 Jdbi는 JDBC보다 조금 더 발전된 형태의 SQL builder로 생각이 되었습니다!! (https://stackoverflow.com/questions/5819392/what-is-the-difference-between-jdbc-and-jdbi, 당연히 단편적으로만 아는 내용이라 틀릴 수도 있습니다!)

@Transactional 어노테이션의 경우 JPA뿐 아니라 JdbcTemplate, MyBatis(iBatis)에서도 활용이 가능합니다! (라이브러리 및 버전에 따라 추가적인 옵션이 일부 필요할 수는 있어요!!) 트랜잭션을 시작하고 관리하는 부분을 서비스 계층의 역할로 생각하는 이유를 조금 더 설명드리면 좋을 것 같은데요! 약간 옛날 얘기부터 시작해보도록 하겠습니다!!!

옛날에는... 그러니까 JPA가 탄생하기 전에는 Jdbc를 사용해 MySQL에 직접적으로 쿼리를 날리는 것이 유일한 방법이었어요!! 당연히 SQL도 직접 작성해주어야 했고요! 하지만 이렇게 SQL을 직접 작성하는 것에는 몇 가지 단점이 있었습니다.

1. SQL은 문자열로 작성하기 때문에 실수할 수 있고, 실수를 인지하는 시점이 느리다.

2. 특정 DB에 종속적이게 된다.

   1. MySQL에 대한 SQL을 fit하게 문자열로 작성하면 PostgreSQL로 한 번에 갈아타기 어렵죠..!

3. 반복 작업이 많아진다.

4. 데이터베이스의 테이블과 객체는 패러다임이 다르다.

   1. 대표적으로 연관관계와 상속관계가 있습니다!

때문에 이런 문제들을 해결하고, 조금 더 객체지향적인 코드를 작성하기 위해 JPA가 등장하게 되었습니다! (물론, 그 사이에 MyBatis같은 SQLMapper도 등장했고요..!!) 이렇게 JPA가 등장하고 난 이후, Spring에서 계층형 아키텍처를 적용했을 때 일반적인 다음 4단계로 나눠지게 됩니다!

• Controller

• Service

• Repository

• Domain (Business 관심사를 다루는 객체)

이런 상황에서 API 부분은 Controller에, 비즈니스 로직은 최대한 도메인에, 도메인을 가져오거나 DB와 접근하는 부분은 Repository에 들어가게 되었고요!

자연스럽게 여러 도메인에 동시 접근해야 하는 상황이라면 Service에서 그 흐름을 제어해주고, 적절하게 트랜잭션을 걸어주게 되었죠! 물론 서비스가 복잡해질 수록 한 API에서 여러개의 Service를 사용하기도 합니다! 이때 트랜잭션의 다양한 전파 옵션을 사용하기도 하고요! 👍

ex) AController -> AService -> BService + CService -> 다시 AService -> AController 결과 반환

[3. 여러 도메인을 삭제해야 하는 경우의 코드 위치]

이 부분은 아마 이런 말씀이신 것 같아요!!! 이제 A 도메인과 B 도메인을 제거한다고 해볼게요~!! 이때 다음과 같은 2가지 방법이 있습니다.

// 방법 1
// Service
@Transactional
fun deleteAB() {
  aRepository.deleteA()
  bRepository.deleteB()
}

// Arepository
fun deleteA() {
  // A를 지운다
}

// BRepository
fun deleteB() {
  // B를 지운다
}

이 방법은 Service에서 2개의 도메인에 관여하는 방법이죠!

// 방법 2
// Service

fun deleteAB() {
  xxxRepository.deleteAB()
}

@Transactional
fun deleteA() {
  // A를 지운다
  // B를 지운다
}

이 방법은 Repository가 2개의 도메인에 관여하는 방법입니다!

우선 결론부터 말씀드리면 2가지 방법 모두 정상 동작합니다!! Spring Data JPA만 사용하신다면, Repository 안에 자유로운 쿼리 작성에 제한이 있어 조금 어려울 수도 있지만, Querydsl까지 사용하게 되면 정말 자유롭게 함수를 구성하고 @Transactional 어노테이션도 Repository 클래스 내부 함수에 붙일 수 있게 되죠!

하지만 저는 1번 방법을 선호합니다!! 그 이유는...

1. "Service에서 여러 도메인에 대한 흐름 제어"를 해주는 것이 더 자연스럽게 느껴지기 때문입니다!!
둘 모두 성능도 비슷하고 가독성도 크게 다르지 않으니, 더 좋은 방법이란 다른 사람들이 익숙한, 그리고 딱 봤을 때 아~ 이 코드는 여기 있겠네~ 할 수 있는 그런 방법이 될텐데요!! 제가 경험했던 코드들과 함께 했던 분들은 Service에서 여러 도메인에 대한 흐름 제어를 해주시는 것에 대해 더 익숙하시다 보니, 저도 그렇게 느끼는 것 같아요!!

2. 왜 Service에서 여러 도메인에 대한 흐름 제어를 하는 것이 자연스럽게 느껴질까?!
1번과 이어지는 내용으로 매우 개인적인 의견입니다!!
저희가 SW를 개발하며 코드를 작성하다 보면, 결국 여러 개의 객체에 의존해야 하는 상황이 생기게 됩니다. 그리고 동시에 SW에 대한 변경이 이루어졌을 때 side effect를 최소화 하고 싶어 하죠.

이런 관점에서, A와 B를 함께 제거하는 코드가 Service에 있을때, 그리고 Repository에 있을 때를 비교해보겠습니다.

일반적으로 계층형 아키텍처에서 주요하게 다뤄지는 원칙은, 코드의 흐름이 한 방향으로만 가능하다는 점입니다! Controller는 Service를 사용할 수 있지만, Service에서는 Controller를 사용할 수 없고, Service에서는 Repository를 사용할 수 있지만, Repository에서는 Service를 사용할 수 없죠!!

이를 그림으로 표현하면 다음과 같습니다.

좋습니다~!!! 자 이제, 저희가 1번 방법 처럼 Service 계층.. 그 중에 Service 2 에 A와 B를 함께 삭제하는 로직이 작성되었다고 해보겠습니다! 그리고 그 로직을 수정해야 할 일이 생겼어요..! 그 때 영향범위는 어떻게 될까요?! 현재 화살표에서 알 수 있듯이 Controller2와 Service2에 국한될 것입니다!

자 그런데~~ 이번에는 2번 방법처럼 Repository에 A와 B를 함께 제거하는 로직을 작성했다고 해볼게요!! 물론 그 로직을 작성할 초기에는 하나의 Service에서만 활용하고 있을 확률이 높겠지만 사람이 바뀌고, 시간이 흐르면 Service에서는 Repository 로직을 가져다 사용할 수 있기 때문에 그 로직을 여기저기서 가져다 쓰고 있을 겁니다...! 저희가 A Repository 에 그 로직을 작성했다고 해보죠~
그러면 이 로직이 변경될 때의 영향 범위는 무려... 코드 전체가 되게 됩니다!
그래서 아마 많은 분들이 Service 쪽에서 도메인 흐름을 제어하는게 자연스럽다고 생각하시는 것 같아요!! (거듭 강조드리지만 제 생각입니다!) 물론 Service 역시 코드가 복잡해지면 Service 끼리의 의존관계가 생기기도 하지만, 잘 제어하기만 하면 Repository에 도메인 흐름 제어 로직이 들어가는 것보다 훨씬 용이하게 관리할 수 있거든요!

3. 만약 서비스가 확장되어 A와 B를 한 번에 제거하는 대신 '최종적 일관성'을 지켜주는 방식으로 서비스가 발전한다면..?!
최종적 일관성을 지켜주기 위해서는 외부 자원 (API 호출 or Event 전송) 사용이 필요하고 외부 자원을 제어하는 것 역시 Service 계층의 역할입니다! 때문에 원래 B 도메인 제거를 Service에서 해주고 있었다면, 그 부분만 코드를 수정하면 되겠지만, Repository 계층에서 A와 B 도메인 제거를 해주고 있었다면, Repository와 Service 코드 모두 수정이 되기 때문에 수정 범위가 조금 더 클 것 같아요!! 때문에 추후 확장성 측면에서 1번 방법이 조금 더 끌리는 것 같습니다 ㅎㅎㅎ

저는 1번 방법을 선호한다고 말씀드렸지만, 결국 정답이 있다기보다는 함께 협업하시는 분들과의 Align이 중요한 부분이지 않을까 생각됩니다~ 😊😊

혹시 기다리실까봐 여기서 한 번 끊고 4, 5, 6번 댓글로 이어서 말씀드려보겠습니다!!!